chore(deps): bump actions/download-artifact from 4.3.0 to 8.0.2

Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 4.3.0 to 8.0.2. - [Release notes](https://github.com/actions/download-artifact/releases) - [Commits](https://github.com/actions/download-artifact/compare/d3f86a106a0bac45b974a628896c90dbdf5c8093...9000827ccba6bdab643e8b6fd33ac0654aef8333) --- updated-dependencies: - dependency-name: actions/download-artifact dependency-version: 8.0.2 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
chore(security): configure dependency and ownership reviews
2026-11-07 05:56:19 -10:00 · 2026-10-30 09:42:21 +00:00 · 2026-10-30 17:35:34 +08:00 · 2026-10-30 02:27:52 -07:00 · 2026-10-30 02:26:01 -07:00 · 2026-10-30 02:25:43 -07:00
3243 changed files with 301205 additions and 276548 deletions
@@ -0,0 +1,21 @@
+{
+  "name": "rea",
+  "interface": {
+    "displayName": "REA"
+  },
+  "plugins": [
+    {
+      "name": "rea",
+      "source": {
+        "source": "npm",
+        "package": "rea-agents",
+        "version": "6.8.0"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Developer Tools"
+    }
+  ]
+}
@@ -15,6 +15,11 @@ Follow the checkout's [performance priorities](../../../AGENTS.md#performance),
 workflow, not additional permission to execute targets, publish, or merge.
 Use the current contracts, provider prerequisites, and user authorization.

+Reserve performance measurements for changes that target performance or have a
+concrete regression concern. Routine cleanup uses correctness checks and does
+not require this optimization workflow or synthetic benchmarks merely because
+helper calls, imports, or representations change.
+
 Read [the Kuna case study](references/kuna-case-study.md) when selecting a
 reuse strategy or interpreting a benchmark. Its pinned observations illustrate
 tradeoffs; they are not current-provider guarantees or universal speedups.
@@ -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: "49"
+  version: "55"
 ---

 # REA
@@ -17,6 +17,9 @@ readiness or provider commands.

 Installing this skill supplies instructions; it does not register the REA MCP
 server, install analysis engines, or add tools to an already-running agent.
+The exception is a Claude Code or Codex plugin install: the plugin bundles
+this skill and registers its own `rea` server, outside the state that
+`rea setup` and `rea doctor` manage.

 If REA tools are available and their registration is not known to be stale,
 proceed directly to the target. Do not run diagnostics or setup before every
@@ -37,42 +40,23 @@ repeat or known not to have started. If it may already have changed the
 target, or it fails again, tell the user and ask them to restart the MCP
 client. If REA could not start its connection, retry once, then tell the user
 and ask them to restart the MCP client. Do not retry a startup failure that
-returns the same unchanged result. Run `rea doctor` when REA could not start
+returns the same unchanged result. For plugin installs, follow
+[plugin recovery](references/connection-and-recovery.md#rea-installed-as-a-client-plugin).
+For setup-owned registrations, run `rea doctor` when REA could not start
 or tools stay missing after that restart. For `cleanup_incomplete`, a retryable
 capacity limit, or `configuration_invalid`, follow the recovery guide's ladder
 before asking for a restart. Read that guide before a second repair attempt.

-1. Diagnose without changing REA or client configuration. `npx` may download
-   the package and write to npm's cache. For Codex, run
-   `npx -y rea-agents@latest doctor --client codex --json`. Substitute the current
-   supported client: `claude_code`, `claude_desktop`, `codex`, `cursor`,
-   `gemini_cli`, `windsurf`, `devin`, `opencode`, `antigravity`, `copilot_cli`,
-   `commandcode`, `vscode`, `grok_build`, `omp`, or `grok_bot`. `grok_bot` has no local
-   file registration: doctor reports the Grok Bot chat step, and setup does not
-   write `mcp.json`. If the client is unknown, use `doctor --json` and
-   inspect its registration results before choosing a setup scope.
-2. Distinguish the reason. Missing, malformed, or stale registration needs a
-   scoped configuration repair. An aligned registration with no tools in the
-   active session needs a restart/reconnection; doctor cannot prove that the
-   current agent has connected. A missing provider affects only tasks requiring
-   that provider: static JavaScript inspection needs neither Hopper nor Ghidra,
-   and Android inspection has separate bring-your-own JADX/Java prerequisites.
-3. For a configuration repair, prepare the read-only plan:
-   `npx -y rea-agents@latest setup --client codex --dry-run --json`.
-   Use the current client's ID, show its exact proposed paths, backups, and
-   changes, and obtain approval before setup writes configuration or installs
-   Hopper. Setup normally installs the matching bundled skill too; include that
-   replacement in the reviewed plan. After approval, apply the same scope with
-   `npx -y rea-agents@latest setup --client codex --yes`. Add `--install-hopper`
-   only if that separate installation was needed and explicitly approved.
-4. Restart/reconnect the affected agent. Verify that REA tools actually appear
-   in the session, then resume the original investigation. If they remain
-   absent, inspect the client's MCP launch error rather than repeating setup.
+Choose the installation owner before repairing registration. Plugin installs use
+[plugin recovery](references/connection-and-recovery.md#rea-installed-as-a-client-plugin);
+only setup-owned registrations use the guide's
+[registration repair plan](references/connection-and-recovery.md#repair-registration-when-needed).
+A plugin-only doctor result of `missing` does not call for `rea setup`.

 REA setup never installs or upgrades Node.js, npm, Homebrew, Java, Ghidra, IDA,
 JADX, Kuna, Binwalk, or Unblob. Use existing prerequisites; do not install unrelated
 software to repair MCP registration. For an unsupported client, use manual stdio
-registration with a version-pinned `rea-agents` package or continue through the CLI.
+registration with an existing installation’s absolute runtime and entry script, or continue through the CLI.

 A concrete CLI fallback for an operator-supplied JavaScript tree or ASAR is:

@@ -85,8 +69,11 @@ graph, limitations, and unknowns with the same care as an MCP result; the CLI
 returns the Evidence record directly. This fallback does not establish that
 MCP is configured. Native CLI tasks still require their selected engine.
 Prefer an existing `rea` CLI. When none is installed and REA package acquisition
-is within the authorized scope, use `npx -y rea-agents@latest` in its place.
-Configuration repair starts with a read-only setup plan; show paths, backups and
+is within the authorized scope, use `npx -y rea-agents@latest` in its place from a
+trusted directory outside the target project, with absolute target paths. Managed
+setup binds the current installation directly; retain its runtime and package
+cache entry, or restore that installation before repairing its registration.
+For setup-owned registration, configuration repair starts with a read-only setup plan; show paths, backups and
 skill replacement before applying authorized changes. Preserve existing approval
 and target-execution boundaries.

@@ -107,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
@@ -119,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.
@@ -158,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
@@ -344,6 +338,11 @@ leaves its database open. The modern headless profile creates and closes an
 owned private database without saving. Installation and registration reuse
 [mrexodia/ida-pro-mcp](https://github.com/mrexodia/ida-pro-mcp); see the
 [IDA provider guide](https://github.com/morluto/rea/blob/main/docs/ida-provider.md).
+For migration to the separate native IDA MCP plugin, follow the guide's
+[legacy attached migration](https://github.com/morluto/rea/blob/main/docs/ida-provider.md#migrate-a-legacy-attached-registration).
+Replace the upstream registration explicitly; modern mrexodia tools are not the
+native profile. Native attachment preserves the database but does not provide
+direct callers; check session availability and the guide's verification limits.
 Proceed directly to `analyze_function`, pseudocode, or function/string searches
 after opening; IDA does not supply `binary_overview`. Consult session availability
 when composing broader workflows. Modern direct callers and unsupported dossier
@@ -374,12 +373,16 @@ native target whose analysis tool operates on the active target. Do not call an
 unadvertised tool; inspect `binary_session` with `{}` and its
 `result.tool_availability` for availability reasons and remediation. Expand each
 group's `names` into entries, inheriting the inventory-level client requirements
-unless the group overrides them. In its closed effect and annotation vocabularies,
-listed flags are true and omitted known flags are false. The grouped name union
-is the complete tool inventory; use `tools/list` for canonical tool schemas.
-Provider candidate facts describe possible providers, while top-level session
-capabilities describe the current route and `analysis_provider_binding` names the
-selected provider. Do not treat those scopes as interchangeable.
+unless the group overrides them. The grouped name union is the complete tool
+inventory; use `tools/list` for canonical tool schemas. The default summary keeps
+each provider candidate's availability and target-support status, code and
+reason; `omitted_fields` lists what it leaves out. Request `{"detail": "complete"}`
+only when you need provider diagnostics, candidate capability sets, or tool
+surface, effect and annotation flags; in those closed flag vocabularies, listed
+flags are true and omitted known flags are false. Provider candidate facts
+describe possible providers, while top-level session capabilities describe the
+current route and `analysis_provider_binding` names the selected provider. Do
+not treat those scopes as interchangeable.

 For a Ghidra startup timeout on a large native target, follow
 [deadline recovery](references/native-and-artifacts.md#ghidra-startup-deadline-recovery)
@@ -13,6 +13,27 @@ own APK path and explicit selectors; do not open a native session first.
 Choose an `overload_index` from the class inventory when methods are ambiguous
 instead of guessing.

+For JNI implementations, discover `inspect_android_jni_bindings`. Select raw
+DEX class/method identities and optional descriptors, ABI or logical library
+paths. Prefer `detail: "summary"`; complete Evidence remains retained and
+`android-jni` views page declarations, libraries, candidates or binding rows
+with exact fields. Global native-pair ambiguity survives class selection.
+Preserve slot/relocation provenance and source coverage: matched means observed
+candidate presence; partial scans do not establish uniqueness or absence.
+This reads DEX/ELF bytes without loading the APK into the decompiler or executing
+target code. Runtime registration and loading remain unknown. See the
+[JNI guide](https://github.com/morluto/rea/blob/main/docs/android-analysis.md#link-native-declarations-to-jni-candidates).
+
+For an R8/ProGuard release build with its `mapping.txt`, pass the absolute
+`mapping_path` to `inspect_android_class` or `inspect_android_method`. Prefer
+`detail: "summary"` to receive normalized symbols or the selected body without
+duplicate raw class metadata. Complete Evidence stays retained under the linked
+parent ID and can be exported; CLI summary delivery requires `--evidence_output`.
+Omitted or complete detail preserves the full inline response. Keep
+selecting by observed names; the separate `mapping` block reports each symbol
+as `mapped`, `ambiguous` or `unmapped` after checking DEX types and prototypes.
+REA does not verify that the mapping belongs to the APK build.
+
 The provider requires a separately supplied headless JADX MCP JAR 0.7.1 and
 Java 17 or newer. `REA_JADX_MCP_JAR` selects the absolute JAR path; `JAVA_HOME`
 can select Java. Use `rea doctor --provider jadx --json` to check the JADX
@@ -17,12 +17,12 @@ does not establish which server an approval wildcard covers. See

 | Observation                                                     | Meaning and next step                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
 | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| No REA tools in the active session                              | Inspect registration with `rea doctor --client codex --json`. A skill installation alone does not register MCP.                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+| No REA tools in the active session                              | If REA was installed as a client plugin, follow the plugin section below. Otherwise inspect registration with `rea doctor --client codex --json`. A skill installation alone does not register MCP.                                                                                                                                                                                                                                                                                                                                                                                     |
 | Missing, malformed or stale registration                        | Prepare a scoped setup plan; apply only authorized changes with backups.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
 | Aligned registration, but no connected tools                    | Restart/reconnect the client. Doctor checks registration; it cannot establish the current agent's connection. Inspect the client's launch error if reconnection fails.                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | MCP connection dropped or REA could not start                   | If the connection drops, retry that call once only when it is safe to repeat or known not to have started. If it may already have changed the target, or the same failure returns, tell the user REA's connection failed and ask them to restart the MCP client. If REA could not start its connection, retry once, then tell the user and ask them to restart the MCP client. Do not retry a startup failure that returns the same unchanged result. Run `rea doctor` when REA could not start or tools stay missing after restart. Doctor cannot restore a live connection by itself. |
 | `MCP tool call requires approval, but approval policy is never` | Codex rejected the call before REA executed it. Do not install an engine or repeat setup to solve this client-policy decision. See the approval section below.                                                                                                                                                                                                                                                                                                                                                                                                                          |
-| REA returns `provider_unavailable` or an unavailable tool entry | Read that operation's provider diagnostics or `binary_session.result.tool_availability`. Expand each group's tool names and inherit the shared client requirements unless overridden. Use the operation's availability, reason, and remediation; a complete tool catalog does not imply every operation is available.                                                                                                                                                                                                                                                                   |
+| REA returns `provider_unavailable` or an unavailable tool entry | Read that operation's provider diagnostics or `binary_session.result.tool_availability`. Expand each group's tool names and inherit the shared client requirements unless overridden. Use the operation's availability, reason, and remediation; a complete tool catalog does not imply every operation is available. Request `{"detail": "complete"}` only for provider diagnostics.                                                                                                                                                                                                   |
 | `rea` is missing in a child shell, or Node is incompatible      | Inspect the actual shell PATH and launcher/runtime. A prefix installation may be absent from a login shell's PATH; this does not establish a broken MCP registration.                                                                                                                                                                                                                                                                                                                                                                                                                   |

 If the client cannot launch its shell/sandbox helper or read the installed skill,
@@ -116,6 +116,32 @@ is not a recommendation to change it. Do not invent a setting. Host memory and
 - `invalid_request`: correct the reported fields from the current schema. Do
  not repeat the unchanged call.

+## REA installed as a client plugin
+
+A Claude Code or Codex plugin owns its `rea` server and this skill. Doctor's
+`--client` and `--skill` checks and `rea setup` read and write only
+setup-owned state, so for a plugin-only install they report `missing`, and
+applying setup would add a second `rea` server. If this skill was loaded from
+a plugin, or the client lists a `rea` plugin, do not prepare a setup plan for
+missing tools. Instead:
+
+- Check that the plugin is installed and enabled with the client's own
+  listing: `claude plugin list` and `/mcp` in Claude Code, `codex plugin list`
+  in Codex.
+- Restart or reconnect the client, then read its launch error for the `rea`
+  server if tools are still absent. The plugin starts its bundled runtime; a missing build or version mismatch
+  requires a reinstall, or a fresh build when developing from source.
+- Check analysis engines through the connected server's
+  `binary_session.result.tool_availability`. `rea doctor --provider <id> --json`
+  from a shell reports that shell's environment, which can differ from the
+  environment the client gave the plugin server. If you still run it through
+  the package runner, use the version pinned in the plugin manifest's server
+  entry (`rea-agents@<version>`), not `@latest`, so it matches the server the
+  plugin starts.
+
+Use the setup repair below only when the user wants a setup-owned registration
+instead of the plugin, and remove or disable the plugin first.
+
 ## Repair registration when needed

 For Codex:
@@ -130,7 +156,10 @@ Use the current supported client's ID: `claude_code`, `claude_desktop`, `codex`,
 `copilot_cli`, `commandcode`, `qwen_code`, `vscode`, `trae`, `grok_build`, `omp`, `pi`,
 `hermes`, `qoder`, `droid`, `zcode`, `dsh`, `freebuff`, or `grok_bot`. If unknown, inspect `doctor --json` before choosing a
 scope. `grok_bot` uses a chat registration step rather than local `mcp.json`.
-For unsupported clients, use version-pinned manual stdio registration or CLI.
+For unsupported clients, use manual stdio registration with the selected
+installation’s absolute runtime and entry script, or continue through the CLI.
+Acquire packages from a trusted directory outside the target project. Keep a
+package-runner installation and its runtime available while registrations use it.

 Show the plan's exact paths, backups, changes and bundled-skill replacement.
 Obtain approval for writes when that concrete scope is not already authorized,
@@ -23,6 +23,14 @@ again if a hint names a gap, then writes the bundle with
 - Map the application first with `inspect_web_page` (and `capture_web_screenshot`
  when layout matters): the login form's locators, and the API calls behind the
  pages that list and edit the entities the user asked about.
+- `inspect_web_page` cannot sign in. To see pages behind sign-in, run a short
+  `capture_browser_scenario` that signs in and opens them, with
+  `"capture": {"after_each_step": ["accessibility"]}` (`"dom"` for markup).
+  Read a step's tree with `inspect_analysis_view`, `view: {kind:
+  "browser-scenario", collection: "text", step_index, artifact:
+  "accessibility", offset: 0, limit: 2048}`, paging with `offset`. Capture
+  options are only `after_each_step`, `at_end`, `events`, `network` and
+  `limits`.

 ## Record a session an environment can learn writes from

@@ -80,62 +88,123 @@ shape, with the application's own locators, paths and headers:
      "path": "/api/folders",
      "expected_status": [200]
    },
+    {
+      "step_id": "new-folder-1",
+      "action": "click",
+      "timeout_ms": 15000,
+      "locator": { "kind": "role", "role": "button", "name": "New folder" }
+    },
+    {
+      "step_id": "folder-title-1",
+      "action": "fill",
+      "timeout_ms": 15000,
+      "locator": { "kind": "css", "selector": "input[name=title]" },
+      "value": { "source": "literal", "value": "Scratch folder 1" }
+    },
    {
      "step_id": "create-folder-1",
+      "action": "click",
+      "timeout_ms": 15000,
+      "locator": { "kind": "role", "role": "button", "name": "Create" },
+      "save_response": {
+        "method": "POST",
+        "path": "/api/folders",
+        "save": [{ "name": "folder_1", "json_pointer": "/id" }]
+      }
+    },
+    {
+      "step_id": "read-folder-1",
      "action": "request",
      "timeout_ms": 15000,
-      "method": "POST",
-      "path": "/api/folders",
-      "json": { "title": "Scratch folder 1" },
-      "headers": [
-        {
-          "name": "X-CSRFToken",
-          "value": { "source": "cookie", "name": "csrftoken" }
-        }
-      ],
-      "expected_status": [200, 201]
+      "method": "GET",
+      "path": "/api/folders/{saved:folder_1}",
+      "expected_status": [200]
    }
  ]
 }
 ```

-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
   user sees.
 2. Read with `request` steps: each collection the environment needs, twice
-   before any write, so fields that change on their own show up; one item of
-   each.
-3. Use `request` steps only when the API lets the caller choose each scratch
-   object's ID or a prior read already established it. Request paths are fixed
-   strings; no action substitutes a value from an earlier response. For
-   server-assigned IDs, create through the UI and open the new object's detail
-   view to record its read, edit and delete through UI actions. If that journey
-   cannot be scripted, leave the write unserved and report the limitation;
-   never guess an ID or create objects with no supported cleanup path.
+   before any write, so fields that change on their own show up; then each
+   object a list shows by id, up to ten per collection. An object known only
+   from a list that leaves out fields its own read shows cannot be read by id
+   or updated in the environment.
+3. Write the way the application's UI does: fill its forms and click its
+   buttons, so each request carries the fields the UI sends, including ones
+   the server would otherwise derive. Give the click or key press that submits
+   a create `save_response` to keep the new object's ID, then `goto` its page
+   (`/items/{saved:item_1}`) or read it with a `request` step. Never guess an
+   ID, and never create a probe object to learn the next one. Write with
+   `request` steps instead only when the UI cannot reach the operation (an
+   API-only resource, or a UI that does not call the JSON API), or when coverage
+   withholds the UI-shaped write as `unexplained-change` or `contradicted`;
+   that counts as one of the two re-recordings. A `request` step write that
+   coverage withholds that way usually lacks fields the UI sends: record it
+   through the UI instead. If a journey cannot be scripted, leave the write
+   unserved and report the limitation.
   Record two numbered scratch objects per write type,
   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`).
-5. Update both objects and read each back; delete both and read each back
-   (expect 404) and the list.
+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. 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
+   requires each member both creates filled in and lets a caller leave out one
+   a create left out or sent empty, so an agent that names only a title is not
+   refused for fields it had no reason to set.

 About `request` steps:

 - `path` is on the start URL's origin; the page must be on that origin.
 - Header values are literals, declared secrets, a cookie the browser holds
-  (`{source: "cookie", name}`), or a local storage entry
-  (`{source: "local_storage", key, json_pointer}`), with an optional
-  `prefix` such as `"Bearer "`. Copy the headers the application's own
-  requests send (a CSRF header, a bearer token). Values read from the page
-  are redacted from records made after they are read, not from the login
-  response that returned them, and values shorter than 8 characters are not
-  redacted at all.
+  (`{source: "cookie", name}`), a local storage entry
+  (`{source: "local_storage", key, json_pointer}`), a saved value
+  (`{source: "saved", name}`), or Basic credentials
+  (`{source: "basic_credentials", parts: [username, password]}`, sent as the
+  base64 of `username:password` and redacted), with an optional `prefix` such as
+  `"Bearer "` or `"Basic "`. Each credential part is a literal, secret, saved
+  value, cookie or local storage entry, so a header the frontend builds from a
+  login token (the username and the token) can be copied too; the password is
+  a secret or saved value, never a literal. Copy the
+  headers the application's own requests send (a CSRF header such as
+  `X-CSRFToken` from the `csrftoken` cookie, a bearer token). Values read from the page are redacted from records made after they
+  are read, not from the login response that returned them, and values
+  shorter than 8 characters are not redacted at all.
+- `save: [{name, json_pointer, secret}]` keeps a string or number from the
+  step's JSON response, such as the created object's `/id`, for later steps;
+  `secret: true` redacts it, as for a token the API returns, so mark every
+  saved token, key or session value secret. This also protects the selected
+  source response before its body or headers are retained. Compressed or
+  unknown-size UI responses cannot supply saved values. On a `click` or `press`,
+  `save_response: {method, path, save}` keeps values from the response to the
+  new request observed while the step waits (`{*}` in `path` matches one segment).
+  Matching does not prove UI causality: choose a path distinct from polling;
+  multiple observed matches fail as ambiguous. The step
+  fails unless a 2xx JSON response arrives before its `timeout_ms`. Later
+  steps send a saved value as `{saved:name}` in a request `path` (and its
+  query) or a `goto` URL; in the `json` body, where a string that is only
+  `{saved:name}` keeps the saved JSON type; or as `{source: "saved", name}` in
+  a header or credential part.
 - Reading a page value makes later bodies costlier to keep: after a CSRF
  token, bodies over about 47 KiB are kept as `unavailable`. When the API
  returns larger responses, raise `capture.limits`
@@ -172,20 +241,22 @@ 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`       | Stop: the body is not a JSON object.                                                          |
+| 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; the first attempt's objects may still
-exist.
+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
+id that capture shows): the environment starts from what the recording first
+reads, so a leftover object becomes seeded data that write tasks then find.
 New browser scenario captures include request times, so a fully timed capture
 can learn a write clock and serve updates that stamp modification times. Older
 captures or ones missing a request start keep record order and learn no clock.
@@ -46,7 +46,10 @@ 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
@@ -78,6 +78,15 @@ classification, and unavailable sources never establish route reachability or
 the complete application route denominator. See the
 [route inventory guide](https://github.com/morluto/rea/blob/main/docs/javascript-route-inventory.md).

+For captured endpoint observations and inference facts, `analyze_web_bundle`
+also accepts `view: {kind: "web-bundle", collection: "endpoints", limit: 32}`
+with `detail: "summary"`. Read later `endpoints`, `inferences`, or `summary`
+pages from the retained parent. Filter before requesting detail; retain
+`source_index` together with parent ID and collection, and request `location`
+or `basis` when tracing sources. Page exhaustion does not mean producer
+completeness: check `completeness`, structured `source_unknowns`, and limitations.
+Endpoint candidates remain inferences rather than confirmed network behavior.
+
 ## Read a module without repeating analysis

 Use the actual returned parent ID, on the same connection, as `source.evidence_id`.
@@ -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.

+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:
+`REA_NATIVE_MATCHING_REPRESENTATION_BYTES`. The default is 96 MiB; the policy
+range is 1 byte to 1 GiB and does not bound process RSS. Keep the complete
+inventories: splitting them changes global name/body uniqueness.
+
 ## Apple app resources

 Use `open_bundle_resources` with the selected app path, then `inspect_plist`,
@@ -316,26 +323,43 @@ run, use `observe_native_calls` with explicit breakpoints and a bounded
 `duration_ms`/`max_events`. It launches a new process under LLDB, so the target
 runs and may change files or use the network. Hardened-runtime targets need the
 `get-task-allow` entitlement.
-Function breakpoints use exact LLDB runtime names: a Darwin C `_main` static symbol
-may be `main` at runtime. REA does not translate names. Set `module` to the image
+Function breakpoints use exact LLDB runtime names: pass an `inspect_macho` export
+or import `runtime_name` (`main`), not its symbol-table `name` (`_main`). REA does
+not translate breakpoint names. Set `module` to the image
 file name when selecting that image only; otherwise loaded system images also
 match. Inspect retained locations and module paths before attributing a call.

 Use `binary_session` with no arguments to check the open target, selected
-provider, and alignment. Its default `result.tool_availability` carries a
-complete inventory grouped by shared facts. Expand each group's `names` and
-inherit the inventory-level client requirements unless a group overrides them;
-availability, reasons, remediation, modes, and flags remain inline. The
-`effects` and `annotations` arrays name true flags from fixed vocabularies, so an
-omitted known flag is false. `tools/list` remains the canonical source for full
-tool schemas when target or provider state changes.
+provider, and alignment. Its default summary `result.tool_availability` carries
+the complete tool inventory grouped by current status. Expand each group's
+`names` and inherit the inventory-level client requirements unless a group
+overrides them; availability, reasons, remediation, and modes remain inline.
+Provider candidates keep availability and target-support status, code, and
+reason. `omitted_fields` names what the summary leaves out; `{"detail":
+"complete"}` adds provider diagnostics, candidate capability sets, and tool
+surface, `effects`, and `annotations`. Those arrays name true flags from fixed
+vocabularies, so an omitted known flag is false. `tools/list` remains the
+canonical source for full tool schemas when target or provider state changes.

 Provider capability groups carry provider identity and ordered limitations.
 Prepend each set's `shared_limitations` to a group's `limitations` to recover the
-operation's full ordered list. Candidate capabilities describe possible
-providers. Top-level session capabilities describe the current route, and
+operation's full ordered list. Candidate capabilities, returned with complete
+detail, describe possible providers. Top-level session capabilities describe the current route, and
 `analysis_provider_binding` identifies the selected provider.

+## Reuse caller-selected Ghidra analysis
+
+When the caller supplies an expanded project, configure `REA_GHIDRA_PROJECT_PATH`
+(the `.gpr` marker) and optionally `REA_GHIDRA_PROGRAM_NAME` (one root program),
+then restart/reconnect before `open_binary`. CLI uses the same configuration.
+REA opens only a fingerprint-bound owned copy with `-process -noanalysis -readOnly`;
+original project files are not opened by the engine or saved. Database edits,
+import overrides and repair scripts are unavailable in this mode. Treat original
+analysis completeness/settings as unknown and prior edits as caller-project state.
+The program's recorded import digest must match the target; changed project content
+requires reopening for a fresh profile. See the
+[setup and preparation guide](https://github.com/morluto/rea/blob/main/docs/installation.md#reuse-an-existing-ghidra-project).
+
 ## Ghidra startup deadline recovery

 `provider_timeout` during the first Ghidra query can cover import, auto-analysis,
@@ -399,6 +423,21 @@ encoded in bounded batches.
 The 25000 ms Cutter request deadline and the 256-candidate discovery budget
 still have no runtime override.

+## Selected native facts and call graphs
+
+For a large `get_call_graph`, or repeated `procedure_address`,
+`procedure_callees`, `procedure_callers` and `resolve_containing_procedure`
+queries, select `detail: "summary"` when the first 64 recorded observations
+suffice. Read further `native-observation` pages from the returned parent Evidence
+ID. Graph message IDs index that page's exact-text dictionary; keep level,
+source index, failed nodes, and partial/unknown relationship coverage.
+Read referenced source context through `native-context` facets `overview`,
+`analysis-profile`, `limitations` and `result-limitations`. Reuse inspected
+context/profile values only for the same digest; until caveats are read,
+interpretation beyond the returned facts remains unknown. Complete Evidence
+remains retained and exportable. Small complete replies can cost fewer tokens
+than additional context/page calls; count the completed task and discovery.
+
 ## Static memory and original file bytes

 For Ghidra, `read_bytes` reads initialized analysis memory, including loader
@@ -426,6 +465,14 @@ loaded bytes, file mappings, relocations and the entry against the immutable
 snapshot. Keep `mismatch` and `unsupported` explicit. Verified import covers the
 reported static image, not runtime DOS or PC-98 hardware behavior.

+For a large load-image report, select `detail: "summary"` and query its
+`parent_evidence_id` with `inspect_analysis_view` kind `native-load-image`.
+Choose a collection such as `relocations` or `mappings`, select only needed
+fields, and page with offset/limit. Original indices preserve same-address
+alternatives. Null collections remain unrecorded or inapplicable; paging does
+not upgrade unsupported verification. CLI requires `--evidence_output` for
+summary delivery so complete source Evidence remains accessible.
+
 For Ghidra decompilation, `procedure_pseudo_code` also accepts `procedure: "file-offset:0x..."`; CLI `rea decompile <path> --file-offset=0x... --provider ghidra` resolves the source byte offset internally. An unresolved 0x-prefixed numeric procedure selector also falls back to a unique file mapping. Existing symbols and analysis addresses win; multiple mappings fail as ambiguous. Preserve the returned file-offset and address locations and raw selection observations. ELF virtual addresses are distinct from file offsets; never assume an arbitrary offset plus image base is an analysis address.

 Complete function body ranges use inclusive ends and can contain gaps. Do not
@@ -469,6 +516,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

@@ -556,6 +608,7 @@ discovery are unsupported. Windows Ghidra P0 admits raw images only for `6502`.

 ### 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.

 ## Offline PE resource inventory
@@ -604,3 +657,58 @@ page cannot prove absence in unknown coverage. Retained views are historical,
 not fresh filesystem checks. No decryption, Godot resource decoding, GDScript
 decompilation or target execution is provided. See
 [Godot PCK](https://github.com/morluto/rea/blob/main/docs/godot-pck.md).
+
+UnityFS AssetBundle containers (`.bundle`, `.ab`, YooAsset packages and other
+byte-identified files) list `CAB-*` SerializedFiles and `.resS` members with
+header and node facts; none/LZ4/LZ4HC member blocks stream on demand. Bundles
+declaring asset-bundle encryption keep header facts with unknown directory
+coverage; LZMA member bytes retain named occurrences with unavailable hashes.
+Virtual member offsets are not physical carrier locations. Format 6–8 readers
+cache one decoded block and support retained filtered/paged views. No
+decryption or SerializedFile object decoding is provided. See
+[UnityFS](https://github.com/morluto/rea/blob/main/docs/unityfs.md).
+
+U-Boot legacy uImages use the same inspection/extraction workflows. Prefer a
+retained summary and selected inventory views for header facts or component
+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).
+
+## 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).
@@ -86,6 +86,8 @@ Page-declared WebMCP tools are untrusted inventory and are never invoked by REA.
  browser and profile. Check `browser.cleanup` for the outcome.
  Request only the DOM, accessibility, or network details needed for the question.
  The default final capture contains the URL; step outcomes are reported separately.
+  For multi-step flows with trees or events, select `detail: "summary"` and page
+  exact steps, transactions, text slices or events with `inspect_analysis_view` kind `browser-scenario`.
  Add a wait action for the expected page state before capturing it. Report that
  REA performed the declared actions.

@@ -0,0 +1,21 @@
+{
+  "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
+  "name": "rea",
+  "description": "Reverse engineer anything with agents, from app behavior down to native binaries.",
+  "owner": {
+    "name": "morluto",
+    "url": "https://github.com/morluto"
+  },
+  "plugins": [
+    {
+      "name": "rea",
+      "description": "Reverse engineer anything with agents, from app behavior down to native binaries.",
+      "source": {
+        "source": "npm",
+        "package": "rea-agents",
+        "version": "6.8.0"
+      },
+      "category": "development"
+    }
+  ]
+}
@@ -0,0 +1,29 @@
+{
+  "name": "rea",
+  "version": "6.8.0",
+  "description": "Reverse engineer anything with agents, from app behavior down to native binaries.",
+  "author": {
+    "name": "morluto",
+    "url": "https://github.com/morluto"
+  },
+  "homepage": "https://rea.tools/",
+  "repository": "https://github.com/morluto/rea",
+  "license": "MIT",
+  "keywords": [
+    "reverse-engineering",
+    "binary-analysis",
+    "decompiler",
+    "mcp-server"
+  ],
+  "skills": "./skills",
+  "mcpServers": {
+    "rea": {
+      "command": "node",
+      "args": [
+        "${CLAUDE_PLUGIN_ROOT}/scripts/plugin-mcp-launcher.mjs",
+        "6.8.0"
+      ]
+    }
+  },
+  "icon": "./assets/rea-plugin.png"
+}
@@ -0,0 +1,13 @@
+{
+  "mcpServers": {
+    "rea": {
+      "command": "node",
+      "args": [
+        "./scripts/plugin-mcp-launcher.mjs",
+        "6.8.0"
+      ],
+      "cwd": ".",
+      "startup_timeout_sec": 30
+    }
+  }
+}
@@ -0,0 +1,40 @@
+{
+  "name": "rea",
+  "version": "6.8.0",
+  "description": "Reverse engineer anything with agents, from app behavior down to native binaries.",
+  "author": {
+    "name": "morluto",
+    "url": "https://github.com/morluto"
+  },
+  "homepage": "https://rea.tools/",
+  "repository": "https://github.com/morluto/rea",
+  "license": "MIT",
+  "keywords": [
+    "reverse-engineering",
+    "binary-analysis",
+    "decompiler",
+    "mcp-server"
+  ],
+  "skills": "./skills",
+  "mcpServers": "./.codex-plugin/mcp.json",
+  "interface": {
+    "displayName": "REA",
+    "shortDescription": "Reverse engineer anything",
+    "longDescription": "Reverse engineer anything with agents, from app behavior down to native binaries.",
+    "developerName": "morluto",
+    "category": "Developer Tools",
+    "capabilities": [
+      "Interactive",
+      "Read",
+      "Write"
+    ],
+    "websiteURL": "https://rea.tools/",
+    "defaultPrompt": [
+      "Use REA to explain how this binary implements a feature.",
+      "Use REA to compare two versions of this application.",
+      "Use REA to recover the sources from this JavaScript bundle."
+    ],
+    "composerIcon": "./assets/rea-plugin.png",
+    "logo": "./assets/rea-plugin.png"
+  }
+}
@@ -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
@@ -144,6 +144,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
@@ -317,7 +320,7 @@ jobs:
        id: npm-cache
        uses: ./.github/actions/npm-cache
      - run: npm ci
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: rea-test-runtime
          path: .
@@ -426,7 +429,7 @@ jobs:
      - name: Download previous timing report
        if: steps.history.outputs.run-id != ''
        continue-on-error: true
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+        uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: ${{ steps.history.outputs.artifact-name }}
          run-id: ${{ steps.history.outputs.run-id }}
@@ -493,7 +496,7 @@ jobs:
        uses: ./.github/actions/npm-cache
      - if: needs.changes.outputs.code == 'true' && success()
        run: npm ci
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        if: >-
          !cancelled() && needs.changes.outputs.code == 'true' &&
          (needs.test-shard.result == 'success' || needs.test-shard.result == 'failure' ||
@@ -692,11 +695,11 @@ jobs:
          assert.equal(process.arch, process.env.EXPECTED_CI_ARCHITECTURE);
          console.log(JSON.stringify({ platform: process.platform, architecture: process.arch, node: process.version }));"
      - run: npm ci
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: rea-build-cache
          path: .turbo/cache/
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: windows-native-controls
          path: native/windows/build/
@@ -736,7 +739,7 @@ jobs:
        id: npm-cache
        uses: ./.github/actions/npm-cache
      - run: npm ci
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: rea-build-cache
          path: .turbo/cache/
@@ -753,6 +756,14 @@ jobs:
      - name: Run native Apple and process boundary regressions
        run: >-
          npm run test:focused --
+          tests/boundary/providers/hopper/hopperMacLaunchArguments.test.ts
+          tests/acceptance/providers/hopperStartupRecovery.test.ts
+          tests/boundary/providers/hopper/hopperClient.helperFailure.test.ts
+          tests/boundary/providers/hopper/bridgeBootstrapCleanup.test.ts
+          tests/boundary/providers/hopper/bridgeTargetLease.integration.test.ts
+          tests/acceptance/artifactDmgAttachmentRecoveryCli.test.ts
+          tests/boundary/providers/native/nativeDmgArtifactReader.test.ts
+          tests/process-global/dmgCancellationReason.test.ts
          tests/boundary/filesystem/installScript.test.ts
          tests/boundary/filesystem/nibNativeHierarchy.test.ts
          tests/boundary/filesystem/interfaceBuilderBundle.test.ts
@@ -765,6 +776,7 @@ jobs:
          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
@@ -827,11 +839,11 @@ jobs:
          GOMAXPROCS: "2"
          GOMEMLIMIT: "3GiB"
        run: npm run typecheck -- --checkers 2
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: rea-build-cache
          path: .turbo/cache/
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: windows-native-controls
          path: native/windows/build/
@@ -852,6 +864,24 @@ jobs:
      # The matching native artifact establishes real Job Object and private
      # runtime boundaries for these fixtures. Ghidra and Java are not needed;
      # real engine claims remain in the separate controlled-provider workflow.
+      # Run native proofs before the broad curated suite so an unrelated
+      # fixture failure cannot hide the real control and recovery checks.
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
+        with:
+          name: windows-process-boundary-fixture
+          path: .cache/windows-process-boundary/
+      # Passing the fixture adds the breakaway, caller/child token, environment
+      # semantics and ancestor reparse observations, which the lane skips
+      # entirely when it is absent.
+      - run: >-
+          npm run verify:windows-native -- .
+          "${{ github.workspace }}\.cache\windows-process-boundary\process-boundary.exe"
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
+        with:
+          name: windows-native-inspection-fixture
+          path: .cache/windows-native-inspection-fixture/
+      - name: Verify native inspection failure ownership and recovery
+        run: node scripts/verify-windows-native-inspection.mjs
      - name: Run curated Windows capability tests
        run: >-
          npx vitest run --coverage.enabled=false
@@ -868,6 +898,7 @@ jobs:
          tests/boundary/providers/native/artifactProvider.extractionCompleteness.test.ts
          tests/boundary/filesystem/setupUnavailableProvider.test.ts
          tests/boundary/filesystem/windowsNpxRegistration.test.ts
+          tests/boundary/filesystem/claudeDesktopSkillUninstallWindows.test.ts
          tests/boundary/filesystem/clientConfigurationEnvironment.test.ts
          tests/boundary/filesystem/clientConfigurationLayeredEnvironment.test.ts
          tests/acceptance/setup/registrationRuntimeEnvironmentCli.test.ts
@@ -879,6 +910,7 @@ jobs:
          tests/boundary/process/packageNpmInvocation.test.ts
          tests/boundary/process/packedBridgeVerification.test.ts
          tests/boundary/process/windowsOutputCapture.test.ts
+          tests/boundary/process/windowsExecutableSelection.test.ts
          tests/acceptance/webModuleCli.test.ts
          tests/acceptance/webSourceLocationCli.test.ts
          tests/boundary/cli/referenceSourceImportStatus.test.ts
@@ -903,22 +935,6 @@ jobs:
          tests/process-global/runnerCancellation.test.ts
          tests/process-global/windowsOwnedCommand.test.ts
          tests/conformance/providers/ghidra/realGhidraWindowsWorkflow.test.ts
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
-        with:
-          name: windows-process-boundary-fixture
-          path: .cache/windows-process-boundary/
-      # Passing the fixture adds the breakaway, caller/child token, environment
-      # semantics and ancestor reparse observations, which the lane skips
-      # entirely when it is absent.
-      - run: >-
-          npm run verify:windows-native -- .
-          "${{ github.workspace }}\.cache\windows-process-boundary\process-boundary.exe"
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
-        with:
-          name: windows-native-inspection-fixture
-          path: .cache/windows-native-inspection-fixture/
-      - name: Verify native inspection failure ownership and recovery
-        run: node scripts/verify-windows-native-inspection.mjs
      - name: Verify real Node Inspector discovery and observation
        timeout-minutes: 10
        env:
@@ -61,7 +61,7 @@ jobs:
        uses: ./.github/actions/npm-cache
      - run: npm ci
      - if: matrix.platform == 'Windows'
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+        uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: cutter-windows-native
          path: native/windows/build/
@@ -69,12 +69,12 @@ jobs:
        with:
          node-version-file: .nvmrc
      - run: npm ci
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: real-ghidra-windows-native
          path: native/windows/build/
      - run: npm run verify:windows-native:artifact
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: real-ghidra-windows-process-boundary
          path: .cache/windows-process-boundary/
@@ -52,14 +52,14 @@ jobs:
          path: .cache/release-source
          persist-credentials: false
      - name: Download original qualified package
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+        uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: verified-release-package
          run-id: ${{ steps.release.outputs.run_id }}
          github-token: ${{ github.token }}
          path: .cache/verified-package
      - name: Restore original verifier runtime
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+        uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: rea-test-runtime
          run-id: ${{ steps.release.outputs.run_id }}
@@ -422,7 +422,7 @@ jobs:
          package-manager-cache: false
          registry-url: https://registry.npmjs.org
      - name: Download the original qualified package
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+        uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: verified-release-package
          path: .cache/verified-package/
@@ -31,7 +31,7 @@ jobs:
        id: npm-cache
        uses: ./.github/actions/npm-cache
      - run: npm ci
-      - uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: rea-test-runtime
          path: .
@@ -103,7 +103,7 @@ jobs:
          node-version-file: .nvmrc
      - name: Download the verified website
        if: inputs.target == 'both'
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
+        uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
        with:
          name: github-pages
          path: ${{ runner.temp }}/website-archive
@@ -50,7 +50,7 @@ Thumbs.db

 # Local reference sources and analysis artifacts
 /_reference/
-/experiments/analysis-efficiency/results/
+/experiments/analysis-efficiency/

 # Generated website download
 /website/public/examples/notes-example.zip
@@ -10,7 +10,10 @@
    "node_modules/**",
    "CHANGELOG.md",
    "package-lock.json",
+    ".claude-plugin/plugin.json",
+    ".codex-plugin/plugin.json",
    "_reference/**",
-    "third_party/**"
+    "third_party/**",
+    ".codex-plugin/mcp.json"
  ]
 }
@@ -53,9 +53,12 @@ Optimize in this order:
 3. CPU and memory. Avoid unnecessary work and copies; bound concurrency,
   retained state and serialization growth.

-For changes affecting these costs, measure representative completed tasks and
-compare equivalent workflows before and after where available. Report token
-usage, elapsed time, CPU time and peak process-family memory. Separate cold
+Reserve performance measurements for changes that target performance or have a
+concrete regression concern. Routine cleanup uses correctness checks; changes
+to helper calls, imports, or representations alone do not require synthetic
+benchmarks. When measurement is warranted, measure representative completed
+tasks and compare equivalent workflows before and after where available. Report
+token usage, elapsed time, CPU time and peak process-family memory. Separate cold
 and warm runs, label estimates, and state unmeasured costs. Fewer bytes alone
 do not establish fewer tokens or faster analysis.

@@ -2683,7 +2683,7 @@ Read the [6.1 to 6.2 migration guide](docs/migration-6.2.md) before upgrading. R
 * enforce conventional pull request titles ([3a21f16](https://github.com/morluto/rea/commit/3a21f16c1832430765083636511a8c12dbccf2dd))
 * verify installed package with Linux Hopper ([4f97f69](https://github.com/morluto/rea/commit/4f97f699e4d5471557d1ce0ff91e144065d06a61))

-## [0.3.0](https://github.com/morluto/rea/compare/rea-agents-0.2.1...rea-agents-0.3.0) (2026-07-12)
+## [0.3.0](https://github.com/morluto/rea/compare/rea-0.2.1...rea-agents-0.3.0) (2026-07-12)


 ### Features
@@ -2736,7 +2736,7 @@ Read the [6.1 to 6.2 migration guide](docs/migration-6.2.md) before upgrading. R
 * redesign and localize README ([051b6db](https://github.com/morluto/rea/commit/051b6db65687fd14826b6462cd623feb2504f123))
 * redesign and localize README ([910eda6](https://github.com/morluto/rea/commit/910eda6f323ba1151b0771fe5de6c60a91e3d46d))

-## [0.2.0](https://github.com/morluto/rea/compare/rea-0.1.0...rea-0.2.0) (2026-07-12)
+## [0.2.0](https://github.com/morluto/rea/releases/tag/rea-0.2.0) (2026-07-12)


 ### Features
@@ -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
@@ -20,7 +20,7 @@

 **[Website](https://rea.tools/) · [Guides](https://rea.tools/guides/) · [Showcases](https://rea.tools/showcase/)**

-[Quick start](#quick-start) · [How REA works](#how-rea-works) · [What you can analyze](#what-you-can-analyze) · [Showcases](#showcases) · [FAQ](#faq) · [Documentation](#documentation)
+[Quick start](#quick-start) · [How REA works](#how-rea-works) · [What you can analyze](#what-you-can-analyze) · [Showcases](#showcases) · [Build RL environments](#build-rl-environments) · [FAQ](#faq) · [Documentation](#documentation)

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

@@ -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.

@@ -83,12 +83,15 @@ npx rea-agents setup

 Choose your agents, review the proposed changes, and approve them. Setup adds
 REA's MCP server and matching workflow instructions, with backups of existing
-configuration. Restart your agent afterward.
+configuration. Restart your agent afterward. Setup records the selected runtime and REA
+entry script directly. If acquired through a package runner, keep its cache entry
+available. Run package acquisition from a trusted directory outside the target
+project. Installation and recovery details are in the setup guide below.

 Setup supports Claude Code, Codex, Cursor, Gemini CLI, Grok Build and
 [other agents](docs/installation.md#supported-agents). See
 [installation and setup](docs/installation.md) for provider configuration and
-manual MCP registration.
+manual MCP registration and Claude Code/Codex plugin installation.

 MCP uses compact input schemas by default to reduce context overhead. Set
 `REA_MCP_INPUT_SCHEMA_PROFILE=full` in your MCP registration when you need the
@@ -96,6 +99,12 @@ complete advertised field guidance and nested validation details. Both profiles
 keep the full tool set and canonical server validation. See
 "Compact input schema profile" in the MCP contracts guide.

+Complete output schemas are advertised by default. If your client caps the
+complete `tools/list` frame, set `REA_MCP_OUTPUT_SCHEMA_PROFILE=compact` to
+bound each advertised output schema, or `off` to omit output schemas entirely.
+Both settings keep canonical server-side validation and complete structured
+results. See "Output schemas" in the MCP contracts guide.
+
 ### Ask your agent

 ```text
@@ -183,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)                                      |
@@ -276,11 +285,53 @@ historical compiler output.
 [Read the case study](https://rea.tools/showcase/th04/) ·
 [Reconstruction repository](https://github.com/N0zoM1z0/th04)

+### Build RL environments with REA
+
+Record a web app session, turn its API into tools, and export an environment an AI agent can use. Run it with AgentEnv, then add tasks and reward checks for RL training or evaluation.
+
+[Read the guide](https://rea.tools/guides/rl-environments/) ·
+[Watch the video](https://x.com/reatools/status/2112574822584918075?s=20)
+
 If you've used REA on something interesting, we'd love to see it. Share your
 case in an [issue](https://github.com/morluto/rea/issues) or a
 [pull request](https://github.com/morluto/rea/pulls), including the target,
 your question, how REA helped, and what you found.

+## Build RL environments
+
+Give an AI agent a local environment to practice tasks such as finding an issue or creating a folder, without running the original app. Use it for reinforcement learning (RL) or to test how well an agent completes tasks.
+
+REA turns recorded API requests and responses into tools the agent can call. The environment uses the recorded data and supports changes only when the recording confirms their effects.
+
+With REA set up in your agent, replace the example URL and folder tasks below with your own:
+
+```text
+Use REA to build an RL environment from my test web app at
+http://127.0.0.1:3000.
+Cover listing, creating, renaming, and deleting folders. You may create and
+remove test folders. Leave existing data unchanged.
+Save it in a folder named my-env. Check which operations work and tell me
+how to run it.
+```
+
+<details>
+<summary>Use the command line instead</summary>
+
+Use these commands if you already have a file containing the app’s recorded browser requests and responses. Running the result also requires AgentEnv and Docker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA exports a runnable environment with a basic test to check that it starts and responds. Use it with your RL framework to define task goals, add reward checks, and run training.
+
+[Build an environment](https://rea.tools/guides/rl-environments/) ·
+[Environment reference](docs/agent-environments.md) ·
+[Watch the demo on X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## FAQ

 <details>
@@ -293,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>

@@ -377,7 +430,7 @@ Report vulnerabilities through [SECURITY.md](SECURITY.md).

 ## Star history

-🎉 **300,000 GitHub stars — thank you!**
+🎉 **400,000 GitHub stars — thank you!**

 Thanks to everyone using REA, reporting bugs, requesting features, testing builds, and contributing fixes.

@@ -10,7 +10,7 @@ Do not disclose vulnerabilities, proof-of-concept exploits, credentials,
 private binaries, Hopper documents, or private Ghidra projects in a public
 issue.

-Use **Report a vulnerability** in the repository's **Security** tab to submit the report privately. Do not open a public issue to request a private contact channel.
+Use **Report a vulnerability** in the repository's **Security** tab as the preferred way to submit the report privately. If GitHub private reporting is unavailable to you, email [[email protected]](mailto:[email protected]). Do not open a public issue to request a private contact channel.

 Include the affected REA version, operating system/distribution, selected
 provider and version, impact, reproduction conditions, and any suggested
@@ -0,0 +1,10 @@
+# Plugin icon
+
+`rea-plugin.png` is a square adaptation of the left panel of REA's GitHub
+social preview, retrieved on 2026-10-28:
+
+https://repository-images.githubusercontent.com/1209966933/1a3fef9a-be4b-41f4-8830-a94c0e8288cc
+
+The image was adapted with imagegen, preserving the cyan REA lettering,
+pixel typography, orange rule, and taglines. Both plugin manifests reference
+this shared asset; only the PNG is included in the npm package.
@@ -1,5 +1,9 @@
 import com.atxx.jhmcp.*;
 import com.google.gson.*;
+import com.android.tools.smali.dexlib2.Opcodes;
+import com.android.tools.smali.dexlib2.dexbacked.DexBackedDexFile;
+import com.android.tools.smali.dexlib2.dexbacked.DexBackedClassDef;
+import com.android.tools.smali.dexlib2.dexbacked.DexBackedMethod;
 import io.modelcontextprotocol.kotlin.sdk.server.*;
 import io.modelcontextprotocol.kotlin.sdk.types.*;
 import jadx.api.*;
@@ -9,14 +13,22 @@ import jadx.api.plugins.input.data.ICodeReader;
 import jadx.api.plugins.input.data.IMethodRef;
 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.nodes.*;
+import jadx.core.xmlgen.BinaryXMLParser;
 import java.io.PrintStream;
 import java.io.StringReader;
+import java.io.InputStream;
+import java.io.IOException;
+import java.nio.file.Path;
 import java.nio.charset.StandardCharsets;
 import java.util.*;
 import java.util.concurrent.CountDownLatch;
 import java.util.stream.Collectors;
+import java.util.zip.CRC32;
+import java.util.zip.ZipEntry;
+import java.util.zip.ZipFile;
 import kotlin.Unit;
 import kotlin.ResultKt;
 import kotlin.coroutines.Continuation;
@@ -178,6 +190,205 @@ class ReaJadxBridge {
    manifestSnapshot = null;
  }

+  // One bounded DEX at a time, beside the already admitted analysis JVM. The
+  // response allowance accounts for worst-case JSON escaping before retention.
+  private static final int NATIVE_DEX_BYTES = 64 * 1024 * 1024;
+  private static final long NATIVE_TOTAL_DEX_BYTES = 256L * 1024 * 1024;
+  // This JSON is escaped again inside an 8 MiB MCP frame.
+  private static final long NATIVE_JSON_BYTES = 4L * 1024 * 1024;
+
+  /** The bundled decoder allocates its declared UTF-16 length before validating bytes. */
+  private static final class NativeDex extends DexBackedDexFile {
+    private OptionalIndexedSection<String> boundedStrings;
+    NativeDex(byte[] bytes) { super(Opcodes.getDefault(), bytes); }
+
+    @Override public OptionalIndexedSection<String> getStringSection() {
+      if (boundedStrings == null) {
+        var source = super.getStringSection();
+        boundedStrings = new OptionalIndexedSection<>() {
+          @Override public int size() { return source.size(); }
+          @Override public int getOffset(int index) { return source.getOffset(index); }
+          @Override public String getOptional(int index) { return index == -1 ? null : get(index); }
+          @Override public String get(int index) {
+            int offset = getBuffer().readSmallUint(source.getOffset(index));
+            int units = getDataBuffer().readerAt(offset).readSmallUleb128();
+            if (units > NATIVE_JSON_BYTES / 6
+                || units > getDataBuffer().getBuf().length - offset)
+              throw new IllegalArgumentException("DEX string exceeds the native decoding allowance");
+            return source.get(index);
+          }
+        };
+      }
+      return boundedStrings;
+    }
+  }
+
+  private static void checkNativeInterrupted() {
+    if (Thread.currentThread().isInterrupted())
+      throw new java.util.concurrent.CancellationException("Native declaration inventory interrupted");
+  }
+
+  private static final class NativeInventory {
+    final List<Map<String, Object>> methods = new ArrayList<>();
+    final List<String> unknowns = new ArrayList<>();
+    long retainedBytes = 1024;
+    int dexEntries;
+    int examinedDexEntries;
+    int examinedClasses;
+    int examinedMethods;
+    boolean partial;
+    boolean diagnosticLimit;
+
+    void unknown(String reason) {
+      partial = true;
+      long bytes = 64L + reason.length() * 6L;
+      if (unknowns.size() < 16 && retainedBytes + bytes <= NATIVE_JSON_BYTES - 4096) {
+        unknowns.add(reason);
+        retainedBytes += bytes;
+      } else if (!diagnosticLimit) {
+        diagnosticLimit = true;
+        unknowns.add("Additional native-inventory limitations exceed the retained diagnostic allowance.");
+      }
+    }
+
+    boolean retain(Map<String, Object> method, long bytes) {
+      if (retainedBytes + bytes > NATIVE_JSON_BYTES - 4096) {
+        unknown("Native declarations exceed the 4 MiB retained JSON allowance; remaining declarations are unknown.");
+        return false;
+      }
+      retainedBytes += bytes;
+      methods.add(method);
+      return true;
+    }
+
+    Map<String, Object> result() {
+      return Map.of("scope", "apk-root-dex-declarations", "methods", List.copyOf(methods),
+          "coverage", Map.of("status", partial ? "partial" : "complete",
+              "dex_entries", dexEntries, "examined_dex_entries", examinedDexEntries,
+              "examined_classes", examinedClasses, "examined_methods", examinedMethods),
+          "unknowns", List.copyOf(unknowns));
+    }
+  }
+
+  /** Match Android's standard root multidex carriers, without a basename guess. */
+  private static boolean nativeDexEntry(String name) {
+    return name.equals("classes.dex") || name.matches("classes[0-9]+\\.dex");
+  }
+
+  private static byte[] readNativeDex(ZipFile archive, ZipEntry entry) throws IOException {
+    long size = entry.getSize();
+    if (size < 0 || size > NATIVE_DEX_BYTES)
+      throw new IllegalArgumentException("DEX exceeds the 64 MiB single-member read allowance");
+    byte[] bytes = new byte[(int) size];
+    CRC32 crc = new CRC32();
+    try (InputStream input = archive.getInputStream(entry)) {
+      int offset = 0;
+      while (offset < bytes.length) {
+        checkNativeInterrupted();
+        int read = input.read(bytes, offset, Math.min(65536, bytes.length - offset));
+        if (read < 0) throw new IOException("DEX is shorter than its ZIP declaration");
+        if (read == 0) continue;
+        crc.update(bytes, offset, read);
+        offset += read;
+      }
+      if (input.read() != -1) throw new IOException("DEX exceeds its ZIP declaration");
+    }
+    if (entry.getCrc() < 0 || entry.getCrc() != crc.getValue())
+      throw new IOException("DEX does not match its ZIP CRC32 declaration");
+    return bytes;
+  }
+
+  /** Raw DEX ownership precedes JADX's duplicate-class selection and aliases. */
+  static Map<String, Object> nativeDeclarations(Path apk) {
+    NativeInventory inventory = new NativeInventory();
+    try (ZipFile archive = new ZipFile(apk.toFile())) {
+      Map<String, Integer> names = new HashMap<>();
+      var directory = archive.entries();
+      while (directory.hasMoreElements()) {
+        checkNativeInterrupted();
+        ZipEntry entry = directory.nextElement();
+        if (!entry.isDirectory() && nativeDexEntry(entry.getName())) {
+          inventory.dexEntries++;
+          names.merge(entry.getName(), 1, Integer::sum);
+        }
+      }
+      long totalBytes = 0;
+      int entryIndex = -1;
+      directory = archive.entries();
+      while (directory.hasMoreElements()) {
+        checkNativeInterrupted();
+        ZipEntry entry = directory.nextElement();
+        entryIndex++;
+        String path = entry.getName();
+        if (entry.isDirectory() || !nativeDexEntry(path)) continue;
+        if (names.get(path) != 1) {
+          inventory.unknown("Duplicate root DEX entry name cannot be selected uniquely by the ZIP reader: " + path);
+          continue;
+        }
+        if (entry.getSize() < 0 || entry.getSize() > NATIVE_DEX_BYTES
+            || entry.getSize() > NATIVE_TOTAL_DEX_BYTES - totalBytes) {
+          inventory.unknown("Root DEX member exceeds the 64 MiB member or 256 MiB total read allowance: " + path);
+          continue;
+        }
+        totalBytes += entry.getSize();
+        try {
+          DexBackedDexFile dex = new NativeDex(readNativeDex(archive, entry));
+          var classes = dex.getClassSection();
+          for (int classIndex = 0; classIndex < classes.size(); classIndex++) {
+            checkNativeInterrupted();
+            DexBackedClassDef cls = classes.get(classIndex);
+            String type = cls.getType();
+            if (!type.startsWith("L") || !type.endsWith(";"))
+              throw new IllegalArgumentException("Class definition has no reference type");
+            String className = type.substring(1, type.length() - 1).replace('/', '.');
+            // Passing false retains duplicate encoded method references too.
+            for (Iterable<? extends DexBackedMethod> group : List.of(
+                cls.getDirectMethods(false), cls.getVirtualMethods(false))) {
+              for (DexBackedMethod method : group) {
+                checkNativeInterrupted();
+                inventory.examinedMethods++;
+                if ((method.getAccessFlags() & 0x100) == 0) continue;
+                String methodName = method.getName();
+                String returnType = method.getReturnType();
+                long characters = 2L + returnType.length();
+                for (CharSequence parameter : method.getParameterTypes()) {
+                  characters += parameter.length();
+                  if (characters * 6L > NATIVE_JSON_BYTES) break;
+                }
+                long bytes = 512L + 6L * (className.length() + methodName.length()
+                    + path.length() + characters);
+                if (inventory.retainedBytes + bytes > NATIVE_JSON_BYTES - 4096) {
+                  inventory.unknown("Native declarations exceed the 4 MiB retained JSON allowance; remaining declarations are unknown.");
+                  return inventory.result();
+                }
+                StringBuilder descriptor = new StringBuilder((int) characters).append('(');
+                for (CharSequence parameter : method.getParameterTypes()) descriptor.append(parameter);
+                descriptor.append(')').append(returnType);
+                Map<String, Object> row = Map.of("source_index", inventory.methods.size(),
+                    "class_name", className, "method_name", methodName, "descriptor", descriptor.toString(),
+                    "dex_entry", path, "dex_entry_index", entryIndex, "class_index", classIndex,
+                    "method_index", method.getMethodIndex());
+                if (!inventory.retain(row, bytes)) return inventory.result();
+              }
+            }
+            inventory.examinedClasses++;
+          }
+          inventory.examinedDexEntries++;
+        } catch (IOException | RuntimeException failure) {
+          if (failure instanceof java.util.concurrent.CancellationException) throw (RuntimeException) failure;
+          inventory.unknown("Root DEX native declarations could not be fully read from " + path + ": "
+              + failure.getClass().getSimpleName()
+              + (failure.getMessage() == null ? "" : " (" + failure.getMessage() + ")"));
+        }
+      }
+    } catch (IOException failure) {
+      // A failed archive close must fail the operation so the provider retires
+      // its owned JVM; do not cache a result with lost file-resource ownership.
+      throw new IllegalArgumentException("APK ZIP native declaration inventory could not finish its reader", failure);
+    }
+    return inventory.result();
+  }
+
  /** Original archive identity, never a deobfuscated basename or name suffix. */
  private ManifestSnapshot manifest(JadxSession current) {
    if (manifestSession != current || manifestSnapshot == null) {
@@ -190,10 +401,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;
@@ -201,6 +409,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;
@@ -270,7 +495,7 @@ class ReaJadxBridge {
                .map(Object::toString).collect(Collectors.joining(", "))
                + "): " + method.getReturnType().toString();
            return new MethodSnapshot(name, rawName, shortId, List.copyOf(bodyAbsenceMarkers), Map.of(
-                "name", name, "signature", signature,
+                "name", name, "raw_name", rawName, "signature", signature,
                "dex_descriptor", descriptor,
                "is_constructor", method.isConstructor(), "def_pos", 0));
          }).toList();
@@ -280,8 +505,11 @@ class ReaJadxBridge {
          List<Map<String, Object>> valuedFields = new ArrayList<>();
          boolean anyValue = false;
          for (FieldNode field : orderedFields) {
+            // Raw DEX identity for mapping lookups; the display type can carry generics.
            Map<String, Object> entry = Map.of("name", field.getAlias(),
-                "type", field.getType().toString(), "def_pos", 0);
+                "raw_name", field.getFieldInfo().getName(),
+                "type", field.getType().toString(),
+                "dex_type", TypeGen.signature(field.getFieldInfo().getType()), "def_pos", 0);
            fields.add(entry);
            Map<String, Object> value = dexStaticValue(field);
            if (value == null) valuedFields.add(entry);
@@ -293,10 +521,11 @@ class ReaJadxBridge {
            }
          }
          List<String> inner = node.getInnerClasses().stream().map(ClassNode::getFullName).toList();
+          List<String> innerRaw = node.getInnerClasses().stream().map(ClassNode::getRawName).toList();
          Map<String, Object> summary = Map.of(
              "full_name", cls.getFullName(), "raw_name", cls.getRawName(), "name", cls.getName(),
              "method_count", methods.size(), "field_count", fields.size(),
-              "inner_class_count", inner.size(), "inner_classes", inner,
+              "inner_class_count", inner.size(), "inner_classes", inner, "inner_class_raw_names", innerRaw,
              "methods", methods.stream().map(MethodSnapshot::summary).toList(), "fields", List.copyOf(fields));
          // DEX static values are opt-in, so method and reference lookups keep the member-only reply.
          Map<String, Object> summaryWithValues = summary;
@@ -470,6 +699,8 @@ class ReaJadxBridge {
        "available_processors", Runtime.getRuntime().availableProcessors(),
        "java_version", System.getProperty("java.version"),
        "metadata_scope", "parsed_members"));
+    if (name.equals("rea_native_declarations"))
+      return json(nativeDeclarations(Path.of(string(args, "path"))));
    JadxSession current = session();
    if (name.equals("get_app_info")) return json(manifest(current).summary());
    if (name.equals("get_android_manifest"))
@@ -581,7 +812,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", "7", null, null, null),
+    Server server = new Server(new Implementation("rea-jadx-bridge", "9", null, null, null),
        new ServerOptions(capabilities), "", ignored -> Unit.INSTANCE);
    SessionToolsKt.registerSessionTools(server, holder);
    ClassToolsKt.registerClassTools(server, holder);
@@ -601,6 +832,11 @@ class ReaJadxBridge {
        new ToolSchema(null, new kotlinx.serialization.json.JsonObject(Map.of()), List.of(), null),
        "Observed worker JVM and metadata scope", null, null, null, null, null, null);
    server.addTool(diagnostics, (connection, request, continuation) -> bridge.handle("rea_jvm_status", request.getArguments()));
+    registerBridgeTool(server, bridge, "rea_native_declarations",
+        new ToolSchema(null, new kotlinx.serialization.json.JsonObject(Map.of("path",
+            new kotlinx.serialization.json.JsonObject(Map.of("type",
+                kotlinx.serialization.json.JsonElementKt.JsonPrimitive("string"))))), List.of("path"), null),
+        "Original ACC_NATIVE declarations from the admitted APK's standard root DEX members, without loading or decompiling the APK.");
    for (String name : List.of("get_app_info", "get_android_manifest")) {
      String description = name.equals("get_app_info")
          ? "Namespace-aware summary of the exact root AndroidManifest.xml resource."
@@ -434,6 +434,8 @@ public final class ReaGhidraBridge extends HeadlessScript {
                "Ghidra auto-analysis did not complete for this Program"
            );
        }
+        if (descriptor.existingProject && isMutatingOperation(request.method))
+            throw new RequestFailure("method_unavailable", "Existing Ghidra project sessions are read-only");
        return switch (request.method) {
            case "read_binary_inventory_summary" -> binaryInventorySummary(request.params);
            case "inspect_native_load_image" -> inspectNativeLoadImage(request.params);
@@ -486,6 +488,10 @@ public final class ReaGhidraBridge extends HeadlessScript {
        };
    }

+    private static boolean isMutatingOperation(String method) {
+        return method.equals("annotate_native_function") || method.equals("set_address_name") || method.equals("set_addresses_names");
+    }
+
    private JsonObject sessionInfo(SessionDescriptor descriptor) throws Exception {
        boolean timedOut = analysisTimeoutOccurred();
        JsonObject provider = new JsonObject();
@@ -511,14 +517,16 @@ public final class ReaGhidraBridge extends HeadlessScript {
        result.addProperty("run_id", descriptor.runId);
        result.addProperty("profile_digest", descriptor.profileDigest);
        result.add("provider", provider);
-        boolean readOnly = !descriptor.transport.equals("unix-socket");
+        boolean readOnly = descriptor.existingProject || !descriptor.transport.equals("unix-socket");
        result.addProperty("read_only", readOnly);
-        result.addProperty("analysis_complete", !timedOut);
+        if (descriptor.existingProject) {
+            result.add("analysis_complete", JsonNull.INSTANCE);
+            result.addProperty("existing_project", true);
+        } else result.addProperty("analysis_complete", !timedOut);
        result.addProperty("analysis_timed_out", timedOut);
        result.add("capabilities", GSON.toJsonTree(
            java.util.Arrays.stream(CAPABILITIES)
-                .filter(value -> !readOnly || !(value.equals("annotate_native_function")
-                    || value.equals("set_address_name") || value.equals("set_addresses_names")))
+                .filter(value -> !readOnly || !isMutatingOperation(value))
                .toArray(String[]::new)
        ));
        result.add("target", target);
@@ -1305,7 +1313,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");
@@ -1377,6 +1385,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;
@@ -2091,10 +2100,7 @@ public final class ReaGhidraBridge extends HeadlessScript {
        requireKeys(params, Set.of("document", "address"));
        requireDocument(params);
        Address query = requireAddress(params, "address");
-        Function function = currentProgram.getFunctionManager().getFunctionAt(query);
-        if (function == null && query.isMemoryAddress()) {
-            function = currentProgram.getFunctionManager().getFunctionContaining(query);
-        }
+        Function function = functionAtOrContaining(query);
        JsonObject result = new JsonObject();
        result.addProperty("query_address", canonicalAddress(query));
        if (function != null) {
@@ -2110,10 +2116,9 @@ public final class ReaGhidraBridge extends HeadlessScript {
    }

    private JsonArray search(JsonObject params, boolean procedureSearch) throws Exception {
-        requireKeys(
-            params,
-            Set.of("pattern", "mode", "case_sensitive", "document")
-        );
+        Set<String> keys = new HashSet<>(Set.of("pattern", "mode", "case_sensitive", "document"));
+        if (params.has("literal_ascii_candidate")) keys.add("literal_ascii_candidate");
+        requireKeys(params, keys);
        requireDocument(params);
        String expression = requireString(params, "pattern");
        String mode = requireString(params, "mode");
@@ -2124,9 +2129,18 @@ public final class ReaGhidraBridge extends HeadlessScript {
        List<InventoryItem> inventory = procedureSearch
            ? procedures().stream().map(FunctionEntry::item).toList()
            : strings();
-        ValueMatcher matcher = mode.equals("literal")
-            ? literalMatcher(expression, caseSensitive)
-            : regexMatcher(expression, caseSensitive);
+        ValueMatcher matcher;
+        if (mode.equals("literal") && !caseSensitive) {
+            if (!params.has("literal_ascii_candidate"))
+                throw new RequestFailure("invalid_request", "Insensitive literal search requires an ASCII candidate");
+            matcher = literalCandidateMatcher(optionalString(params, "literal_ascii_candidate"));
+        } else {
+            if (params.has("literal_ascii_candidate"))
+                throw new RequestFailure("invalid_request", "ASCII candidate applies only to insensitive literals");
+            matcher = mode.equals("literal")
+                ? literalMatcher(expression)
+                : regexMatcher(expression, caseSensitive);
+        }
        JsonArray items = new JsonArray();
        for (InventoryItem item : inventory) {
            monitor.checkCancelled();
@@ -2283,6 +2297,7 @@ public final class ReaGhidraBridge extends HeadlessScript {
        return function;
    }

+    /** Exact entries include externals; containment applies only to memory addresses. */
    private Function functionAtOrContaining(Address address) {
        Function function = currentProgram.getFunctionManager().getFunctionAt(address);
        return function == null && address.isMemoryAddress()
@@ -2987,7 +3002,7 @@ public final class ReaGhidraBridge extends HeadlessScript {
        if (!currentProgram.getLanguageID().getIdAsString().startsWith("AARCH64:")) {
            return null;
        }
-        Function function = containingFunction(jumpTable.getSwitchAddress());
+        Function function = functionAtOrContaining(jumpTable.getSwitchAddress());
        if (function == null) return null;

        List<Instruction> instructions = new ArrayList<>();
@@ -3487,7 +3502,7 @@ public final class ReaGhidraBridge extends HeadlessScript {

    private boolean unrepresentedCaller(Reference reference, Set<Function> callers) {
        if (!reference.getReferenceType().isCall()) return false;
-        Function caller = containingFunction(reference.getFromAddress());
+        Function caller = functionAtOrContaining(reference.getFromAddress());
        return caller == null || !callers.contains(caller);
    }

@@ -3634,7 +3649,7 @@ public final class ReaGhidraBridge extends HeadlessScript {
        void observe(Reference reference) {
            if (!reference.getReferenceType().isCall()) return;
            // Reference identity follows the same containing-function owner as referenceEdge.
-            Function target = containingFunction(reference.getToAddress());
+            Function target = functionAtOrContaining(reference.getToAddress());
            if (returnedCallees != null && (target == null || !returnedCallees.contains(target)))
                unrepresented++;
            if (target == null) unresolved(reference.getFromAddress(),
@@ -3804,8 +3819,8 @@ public final class ReaGhidraBridge extends HeadlessScript {
        JsonObject result = new JsonObject();
        result.addProperty("source_address", canonicalAddress(reference.getFromAddress()));
        result.addProperty("target_address", canonicalAddress(reference.getToAddress()));
-        Function source = containingFunction(reference.getFromAddress());
-        Function target = containingFunction(reference.getToAddress());
+        Function source = functionAtOrContaining(reference.getFromAddress());
+        Function target = functionAtOrContaining(reference.getToAddress());
        result.add(
            "source_procedure",
            source == null ? JsonNull.INSTANCE : procedureIdentity(source)
@@ -3840,14 +3855,6 @@ public final class ReaGhidraBridge extends HeadlessScript {
        return result;
    }

-    private Function containingFunction(Address address) {
-        Function result = currentProgram.getFunctionManager().getFunctionAt(address);
-        if (result == null && address.isMemoryAddress()) {
-            result = currentProgram.getFunctionManager().getFunctionContaining(address);
-        }
-        return result;
-    }
-
    private static String procedureName(Function function) {
        Symbol symbol = function.getSymbol();
        return symbol == null ? function.getName() : symbol.getName(true);
@@ -4699,11 +4706,18 @@ public final class ReaGhidraBridge extends HeadlessScript {
        return source.name().toLowerCase(Locale.ROOT);
    }

-    private static ValueMatcher literalMatcher(String pattern, boolean caseSensitive) {
-        String needle = caseSensitive ? pattern : pattern.toLowerCase(Locale.ROOT);
+    private static ValueMatcher literalMatcher(String pattern) {
+        return value -> value.contains(pattern);
+    }
+
+    // REA's host owns Unicode simple folding. Keep all non-ASCII source values
+    // for its final predicate, and filter ASCII-only values without Java regexes.
+    private static ValueMatcher literalCandidateMatcher(String asciiPattern) {
+        if (asciiPattern != null && asciiPattern.chars().anyMatch(character -> character > 127))
+            throw new RequestFailure("invalid_request", "ASCII candidate contains a non-ASCII character");
        return value -> {
-            String candidate = caseSensitive ? value : value.toLowerCase(Locale.ROOT);
-            return candidate.contains(needle);
+            if (value.chars().anyMatch(character -> character > 127)) return true;
+            return asciiPattern != null && value.toLowerCase(Locale.ROOT).contains(asciiPattern);
        };
    }

@@ -4752,6 +4766,8 @@ public final class ReaGhidraBridge extends HeadlessScript {
            keys.add("analysis_extensions");
        if (parsed.isJsonObject() && parsed.getAsJsonObject().has("decompile_timeout_seconds"))
            keys.add("decompile_timeout_seconds");
+        if (parsed.isJsonObject() && parsed.getAsJsonObject().has("existing_project"))
+            keys.add("existing_project");
        JsonObject object = requireObject(parsed, keys);
        int decompileTimeout = 0;
        if (object.has("decompile_timeout_seconds")) {
@@ -4768,7 +4784,8 @@ public final class ReaGhidraBridge extends HeadlessScript {
            requireString(object, "provider_version"),
            requireString(object, "profile_digest"),
            object.has("analysis_extensions") ? object.getAsJsonArray("analysis_extensions") : new JsonArray(),
-            decompileTimeout
+            decompileTimeout,
+            object.has("existing_project") && requireBoolean(object, "existing_project")
        );
    }

@@ -4985,7 +5002,8 @@ public final class ReaGhidraBridge extends HeadlessScript {
        String providerVersion,
        String profileDigest,
        JsonArray analysisExtensions,
-        int decompileTimeoutSeconds
+        int decompileTimeoutSeconds,
+        boolean existingProject
    ) {}
    private record Request(int id, String method, JsonObject params, Integer decompileTimeoutSeconds) {}

@@ -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":
@@ -53,7 +53,11 @@ export default defineConfig({
            text: "Web network captures",
            link: "/web-network-captures",
          },
-          { text: "Agent environments", link: "/agent-environments" },
+          {
+            text: "Build RL environments",
+            link: "/agent-environments-quickstart",
+          },
+          { text: "Environment reference", link: "/agent-environments" },
          { text: "Electron observation", link: "/electron-observation" },
          { text: "Electron fuses", link: "/electron-fuses" },
          { text: "Process capture", link: "/process-capture" },
@@ -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
@@ -0,0 +1,204 @@
+# Build RL environments with REA
+
+REA turns a recorded web app session into a runnable environment for training
+and testing AI agents. An agent can practice tasks such as finding an issue,
+creating a folder, or editing a record without running the original app.
+
+REA builds the tools the agent calls, the local data those tools use, and a
+test that checks the environment starts and responds. It supports changes
+when the recording confirms their effects. You can then use the environment
+with your RL framework to set task goals, check rewards, and run training.
+
+## Before you start
+
+Install [REA and its agent integration](installation.md). To record an app,
+you also need a running test instance and a Chrome-family browser. Choose an
+instance where the agent is allowed to create, edit, and delete data. REA
+records the app you provide; you start it and prepare its test data.
+
+To run the exported environment, install the
+[AgentEnv framework](https://github.com/scaleapi/agentenv-framework#install)
+and start Docker. REA's [compatibility check](testing.md#exported-environment-bundles)
+uses AgentEnv version `0.9.1334` with Python 3.12.
+
+There are two ways to build an environment: ask your agent to record the app,
+or start from a recording you already have.
+
+## 1. Record and build with your agent
+
+Give your agent the app URL, the operations you need, your browser's executable
+path, and an output directory. For an app with folders, adapt this prompt:
+
+```text
+Use REA to build an AgentEnv environment from my test web app at
+http://127.0.0.1:3000. Cover listing, creating, renaming, and deleting folders.
+You may create and remove test folders. Leave the existing data unchanged.
+
+Sign in as admin using the password in APP_PASSWORD. Use the browser at
+/absolute/path/to/chromium. Save the environment to
+/absolute/path/to/my-env, which does not exist yet.
+
+Record the session, check which operations the environment supports, and
+export it. Report any unsupported operations and what is missing.
+```
+
+Replace the URL, account, paths, and folder operations with your own. Set
+`APP_PASSWORD` in the environment that starts REA's MCP server so REA can use
+it without putting the password in the prompt.
+
+Your agent inspects the app, records a session, checks the result, and exports
+a folder containing the runnable environment. It reports which operations
+work and which need more evidence. The app is used during recording; the
+exported environment runs from the saved data.
+
+After your agent exports the folder, skip to
+[run the environment](#3-run-the-environment). The next section is an
+alternative for an existing recording.
+
+## 2. Or build from a saved recording
+
+A HAR file records a browser's network requests and responses. Export one
+with API response bodies from your browser's network panel, or use a
+recording you already have. To include create, edit, and delete operations,
+record those actions and the reads that show their results.
+
+Build the environment into a new or empty directory:
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+```
+
+You can also pass capture Evidence JSON saved by REA's
+`capture-browser-scenario` or `inspect-web-network-capture` commands. Here,
+Evidence means REA's saved recording with its source information. The build
+accepts HAR files and those JSON recordings. It reads local data and writes
+the environment folder without contacting the app.
+
+Add `--dry-run` to review the build report without writing the folder. For an
+unreleased REA checkout, use `--package-tarball` with its packed package so
+the exported environment runs the same implementation.
+
+The build report tells you what the environment supports:
+
+| Report field      | What to check                                                                                                            |
+| ----------------- | ------------------------------------------------------------------------------------------------------------------------ |
+| `state`           | Whether the environment can answer from local state or uses recorded-response replay.                                    |
+| `coverage.reads`  | Which read operations use state and which replay recorded answers.                                                       |
+| `coverage.writes` | Which create, edit, and delete operations are supported. Each withheld operation includes a reason and a recording hint. |
+| `warnings`        | Recorded content or local paths to review before sharing the folder.                                                     |
+
+A successful build means the folder was created. Check the report to confirm
+it supports the operations your tasks need. `coverage: null` means the build
+could not prepare state for this environment and it will use replay.
+
+## 3. Run the environment
+
+Whether your agent exported the folder or you built it from a HAR, run it
+with AgentEnv:
+
+```sh
+agent-env run ./my-env
+```
+
+Use the folder path your agent reported if it differs. The first run builds
+the container image, so it needs access to the image and package sources.
+
+REA includes a basic test, called the smoke task. It checks the expected tool
+count and, when a suitable read tool exists, calls it and checks its response
+status. Passing this test shows the environment starts and responds in the
+tested setup. It does not yet score an agent on an application task.
+
+The folder contains the recording, a tool manifest describing the available
+operations, a Dockerfile, environment configuration, and the test. The
+[export reference](agent-environments.md#export-a-bundle) describes each file.
+
+## 4. Add tasks and reward checks
+
+Start with one task the exported tools support. Give it a clear goal and a
+checkable result. For example, if folder creation is supported, ask your
+agent:
+
+```text
+Use this exported environment to add an AgentEnv task that asks an agent
+to create a folder named Practice. Check the saved environment state to
+confirm the folder exists with that name, and use that check to score the
+result. Reset the environment before each run so attempts start with the
+same data. Use the AgentEnv task and verifier formats.
+```
+
+This asks your agent to help build the task and its grading check around the
+environment REA generated. A retrieval task might check an answer against a
+recorded value. A task that changes data should check the resulting state.
+When state is available, the environment supports reset, load, and read-back
+operations for repeatable runs.
+
+Use the [AgentEnv documentation](https://www.agentenvframework.com/docs) for
+task configuration, agent connections, scoring, and execution. Connect the
+resulting tasks to your chosen RL training workflow.
+
+## Improve an operation that is missing
+
+For REA to support a change, the recording needs to show what happened before
+and after it. When recording against your test app:
+
+1. Read the list and an existing item before making changes. Repeat the
+   initial reads to show which values change independently.
+2. Create a test item, read it back, and read the list before the next change.
+   Repeat with a second item and different text.
+3. Edit each test item, then read the item and list again. Leave more than a
+   second between creation and the first edit to show time-dependent changes.
+4. Delete the test items, then read them back and read the list to confirm
+   their removal.
+
+Also record filters, searches, sorting, and paging if your tasks need them.
+The agent should check that every recording step completed before using it.
+The [recording workflow](https://github.com/morluto/rea/blob/main/.agents/skills/reverse-engineer-anything/references/environments.md)
+has the detailed browser instructions, including timeouts and handling IDs
+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`               | 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
+again. A new recording replaces the build input; combining separate recording
+sessions is not supported.
+
+## Compare with the original app
+
+For a stronger check, record a separate sequence of calls against the real
+app, starting from the same test data as the original recording. This is a
+probe. Restore that starting data before each probe sequence, then compare
+the saved probe recordings with the environment:
+
+```sh
+rea environment-compare ./my-env/envs/my-env/manifest.json \
+  --evidence ./my-env/envs/my-env/evidence.json \
+  --probe ./probe-create-edit-delete.json --probe ./probe-reads.json --json
+```
+
+Each probe file must be capture Evidence JSON from REA. The comparison runs
+offline and reports differences in responses, unsupported calls, and missing
+observations. It accounts for supported differences in IDs, times, and
+modeled generated values. Agreement applies to the calls those probes check.
+See the [comparison reference](agent-environments.md#measure-fidelity-against-the-application)
+for the exact rules.
+
+## Before sharing the environment
+
+The exported folder includes retained response bodies and local source paths.
+Standard authentication headers are excluded, but custom headers, query
+values, and body tokens can remain. Review the content you plan to share.
+Credential-name warnings point to values worth reviewing; they do not remove
+those values or establish that the recording contains no credentials.
+
+For direct MCP serving, replay behavior, state controls, and resource limits,
+see the [environment reference](agent-environments.md). The
+[implementation index](specs/agent-environments/README.md) links the contributing
+PRs and their verification records.
@@ -1,5 +1,12 @@
 # Agent environments from recorded captures

+For a first environment, start with the
+[quickstart](agent-environments-quickstart.md): record an app or use a saved
+session, build and run the environment, and add tasks and reward checks.
+The [implementation index](specs/agent-environments/README.md) links
+the contributing PRs and their verification records. This page is the detailed
+command and behavior reference.
+
 Use `rea environment-build` to turn one recorded capture into an agent
 environment bundle in one offline step: a folder `agent-env run` builds and
 runs, whose MCP server answers from what the capture observed. See
@@ -79,8 +86,9 @@ name it `.har`.
  manifest's, unless the capture's origin is a loopback name or an IP literal:
  the capture file then names it (`grafana.har` and `grafana.capture.json`
  become `grafana`) and a `name-from-file` warning says so. A file name that
-  yields no portable label (kebab-case, at most 64 characters, not a Windows
-  device name) is refused; pass `--name`.
+  yields no portable label (kebab-case, at most 63 characters for a DNS service
+  label, not a Windows device name or a label interpreted as an IP address) is
+  refused; pass `--name`.
 - `--package-tarball` works as for the export, and `--capture-timeout-ms`
  as for `inspect-web-network-capture`.
 - `--dry-run` runs every stage and prints the report with `status: "planned"`
@@ -166,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. |
@@ -175,6 +183,7 @@ what to record next; hints never change what is served:
 | `side-effect`         | The write changed something besides its own entity, which the environment does not model.                                                                                                                                                        |
 | `unconfirmed`         | No later read showed the effect. Read the entity and its list after the write.                                                                                                                                                                   |
 | `incomplete-entities` | The write is confirmed, but the views that show its entity cannot render it in full. Read the written entity through every view that lists it.                                                                                                   |
+| `unknown-clock`       | The learned rules generate timestamps, but the capture establishes no global served clock start. Record usable start times and completed durations for every request.                                                                            |

 The bundle ships `evidence.json`, the whole capture Evidence, response bodies
 included. Inspection excludes the values of the standard authentication headers
@@ -196,7 +205,10 @@ attached and a transaction no record represents, and each transaction URL's
 query once. Bodies larger than 4 MiB of UTF-8 text are not
 scanned; `credential-scan-incomplete` counts them and lists up to 20 record or
 event pointers, including base64 bodies whose decoded scan was cut. An empty name
-warning does not establish that these bodies were checked. Names do not establish sensitivity,
+warning does not establish that these bodies were checked. A browser scenario's
+saved values (`save` and `save_response`) named like credentials but not marked
+`secret: true` are recorded unredacted; `credential-named-saved-values` lists up
+to 20 of them by parameter pointer. Names do not establish sensitivity,
 so the build never refuses on them. Capture

 Evidence also records the capture file's absolute path (`subject.local_path`,
@@ -394,7 +406,8 @@ returns that record's recorded response. Selection compares the supplied path
 parameters against the record's path segments at the parameter indexes, then
 the supplied query values against the record's query string, and keeps the
 record with the most matches; ties keep manifest order. A query argument accepts
-one string or an array of strings for repeated values; the array is matched
+one string, a number or boolean sent as its JSON text, or an array of strings for
+repeated values; the array is matched
 against every occurrence in captured order. The raw recorded query remains the
 replay evidence. The result reports
 where the answer came from:
@@ -601,8 +614,9 @@ shape and carries no annotations.
 Path parameters are required strings whose
 description names the segment index, the templating rule and the observed
 values (sampled within the list budget above; the manifest keeps them all);
-query parameter names accept an optional string or array of strings (for
-repeated values in captured order); write methods accept an
+query parameter names accept an optional string, number or boolean (a number or
+boolean is sent as its JSON text) or array of strings (for repeated values in
+captured order); write methods accept an
 optional `body` object described by the recorded top-level key types. Each
 input keeps its own argument: a query name equal to a path parameter's name is
 advertised as `query_<name>`, a query name longer than 64 characters as
@@ -709,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
@@ -723,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
@@ -741,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
@@ -756,11 +774,19 @@ sending a `derived` rule's member to an entity that does not hold the value the
 recorded call found, a nested clock on an entity holding no such object, and a
 rendered answer missing a field the recorded response carried, and an update or delete of an entity the state does not hold answers
 the recorded 400, 404 or 410 of the tool or of an item view of the type, if
-any. A refused call leaves the state unchanged. Values a write generates are
+any. A served delete of a type whose item view has a `deleted_flag` (the
+member, `deleted`, `isDeleted` or `is_deleted`, its reads set `true` on a
+record the application soft-deleted, as EspoCRM does) keeps the entity until
+`data/reset` or `data/add`, within the size `data/add` loads, so a read of it by
+id answers its last fields with that flag `true`. A refused call leaves the
+state unchanged. Values a write generates are
 deterministic: the clock starts at `write_clock` and advances one second per
 served write, sequences take one past both the largest held value and the
 largest they generated, and UUIDs and tokens derive from the state Evidence
-id, tool, field and write count, skipping held values. `data/reset` and
+id, tool, field and write count, skipping held values. If `write_clock` is null,
+plans needing `clock`, `held-clock`, or `nested-clock` retain their learned rules
+but are withheld with `unknown-clock`; other confirmed plans can still be served.
+`data/reset` and
 `data/add` restart the clock, counter and sequences, so the same calls after a
 reset give the same state. Answers carry `state: {"source": "state", "view":
 "create" | "update" | "delete", …}` or `"document-write"`; a bulk answer adds
@@ -864,8 +890,9 @@ names a `document` view once, at its initial document's `path`. The `version`,
 and the `state_evidence_id` and `types` that `data/get` reports, must match
 the served state, so a `data/get` result loads back unchanged. A number without
 an exact native value, or whose serialized spelling would not be read as exact
-(an integer from 2^53 below 1e21, such as `1e20`, in any spelling), or a
-`__proto__` member is refused rather than altered.
+(an integer from 2^53 below 1e21, such as `1e20`, in any spelling), is refused
+rather than altered. Caller data preserves all own JSON members, including
+`__proto__`; unknown members of the state document's structure are refused.
 An invalid document is `-32602` naming the first problem by JSON pointer, as in
 `/rea_state/entities/3/collection` (also in `error.data.path`); a problem
 inside caller data (`fields`, `value`, `types`) is located at that member, so
@@ -974,7 +1001,8 @@ serves replay. The complete tool catalog the bundle serves must also fit the
 server's advertised catalog budget before any files are written. Privately parsed JSON is sealed once so authentication
 and replay share immutable response trees rather than copying the capture repeatedly.
 `--name` replaces the manifest's portable kebab-case name as the env folder and env id
-(Windows device names such as `con` and `lpt1` are refused);
+(at most 63 characters for its DNS service label; Windows device names and
+labels interpreted as IP addresses are refused);
 `--package-tarball <path>` copies a packed `rea-agents` tarball into the env
 folder and makes the Dockerfile install it instead of the registry package and
 remove it in the same layer, which is how a checkout rather than a release is
@@ -992,7 +1020,12 @@ Windows inherits ACLs and REA does not establish owner-only access there. Choose
 an already private Windows destination when captured content needs it.

 The Dockerfile sets `MCP_HOST=0.0.0.0` and `MCP_PORT=18765`, the port the
-framework maps for an MCP server env; the framework's own deploy supplies
+framework maps for an MCP server env, and `MCP_ALLOWED_HOSTS` naming the loopback
+addresses and the environment name, because the container binds outside loopback
+and the server refuses to serve on such a bind without an operator-declared
+allowlist: the framework's published port is reached over loopback and its
+gateway proxies to the env container by the compose service name (the
+environment name). The framework's own deploy supplies
 `MCP_HOST`, `MCP_PORT` and `ENVIRONMENT_NAME`, so the served card carries the
 env's name. It installs Debian's `python3` because the framework's local
 sandbox probes a container's readiness with `python3` inside it, which the slim
@@ -30,15 +30,18 @@ code units; follow `coverage.next_offset`. The page preserves `source_status` an
 `reported_total_bytes`: exhausting retained text does not make a partial decoded
 manifest complete. Complete source Evidence remains exportable under the existing
 session lifetime. Servers without retention reject summary before starting JADX.
-One-shot CLI output remains complete. Older servers require the existing complete
-request after schema discovery. APK authenticity and runtime behavior remain
+One-shot CLI output remains complete by default. Select `--detail summary` with
+`--evidence_output /local/capture.json` to retain complete Evidence before returning
+a linked view. Older servers require the existing complete request after schema discovery. APK authenticity and runtime behavior remain
 unverified.

 ## Manifest component projection

 `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
@@ -76,6 +79,61 @@ capacity limitation appears only when an actual collection limit was reached.
 The projection does not merge manifests, expand resource references, or
 observe runtime enabled/export state.

+`enabled` and `grant_uri_permissions` report only literal component-level
+`android:enabled` and provider-level `android:grantUriPermissions` declarations.
+They are `null` when absent or not a literal boolean; missing attributes are not
+filled from application defaults. A nonliteral declaration gets a limitation.
+`process` preserves the exact component-level `android:process` spelling (including
+empty or symbolic values), or `null` when absent or omitted under the inventory-wide
+1 MiB copy budget. Neither field resolves resources, merges manifest values or
+establishes the effective runtime process or enabled state. The exact boolean
+attributes are retained in `enabled_declaration` and
+`grant_uri_permissions_declaration`, including resource references.
+
+`intent_filters` preserves each filter's source ordinal, exact priority spelling,
+actions, categories and individual data declarations (scheme, host, port, path,
+path prefix/pattern/advanced pattern/suffix and MIME type). These are declarations,
+not computed Android matching rules. `meta_data` lists names; values remain in the
+complete decoded manifest. Component, filter, data and metadata `location` values
+use one-based lines/columns and UTF-16 offsets into that manifest. A component's
+`declaration_index` preserves its original declaration ordinal, including gaps.
+
+`declaration_coverage` distinguishes complete, partial and unknown observations.
+Historical Evidence omits newly introduced fields and defaults coverage to
+`unknown`; omission never establishes absence. Current records contain the fields,
+with null for absent or unresolved scalar declarations. The inventory retains at
+most 32 filters and 64 nested action/category/data/metadata records per component,
+and shares a 1 MiB structured-value copy budget across components. Omitted values
+or unsupported filter constructs mark coverage partial and include a limitation;
+complete retained manifest text remains accessible.
+
+For a small answer, select `detail: "summary"` with an explicit view:
+
+```json
+{
+  "kind": "android",
+  "facet": "components",
+  "actions": ["android.provider.Telephony.SMS_RECEIVED"],
+  "fields": ["name", "permission", "enabled", "process", "intent_filters"],
+  "offset": 0,
+  "limit": 16
+}
+```
+
+The same JSON works with CLI `--view` or retained `inspect_analysis_view`.
+`kinds`, `names` and `actions` use exact matching; names accept either the recorded
+declared or resolved name, actions match any requested action, and different
+filters combine with AND. `exported` matches only explicit declarations, keeping
+`exported_default` separate. Empty selectors match nothing. Every selected row
+retains its parent-array `source_index` and `declaration_coverage`; source coverage,
+parent identity and limitations remain alongside the page. Follow
+`coverage.next_offset`. The 1 MiB projection budget can shorten a page; a single
+oversized row requires fewer selected fields. Exhausting a partial source does
+not establish complete manifest coverage. `facet: "component-summary"` applies
+the same filters and counts kinds, declaration coverage and explicit/default
+exported values separately. Both adapters use the same retained projection;
+repeated pages do not reload JADX.
+
 The service `foreground_service_type` field preserves the declared attribute,
 including an empty value or surrounding spaces; `null` means the attribute is
 absent or the component is not a service. This field does not validate service
@@ -230,6 +288,162 @@ instructions into field declarations, leaving an empty or incomplete method
 body. The selected method's disassembly preserves those instructions and retains
 the same source byte limit and explicit truncation reporting.

+## Apply an R8/ProGuard mapping
+
+Release builds shrunk by R8 or ProGuard rename classes and members. Select the
+build's `mapping.txt` with `mapping_path` on `inspect_android_class` or
+`inspect_android_method`, or `--mapping-path` on the matching CLI command:
+
+```sh
+rea inspect-android-class /path/Example.apk a.b --mapping-path /path/mapping.txt \
+  --detail summary --evidence_output /tmp/class-evidence.json
+```
+
+For agent workflows, select `detail: "summary"` on class and method inspection.
+It preserves the complete normalized member inventory or selected method body,
+including mapping annotations, while retaining duplicate raw provider calls in
+the complete parent Evidence. The reply links that parent's identity and digest;
+export it with `export_evidence_bundle` or read its summary again through
+`inspect_analysis_view`. CLI summaries require `--evidence_output` and return
+the portable bundle path. Omitted or `complete` detail preserves complete inline
+Evidence. Search and reference operations retain their existing contracts.
+Symbol summary views admit at most **1 MiB**, including view context. An admitted
+method's source can already consume that amount; a larger combined summary
+fails explicitly instead of silently truncating facts. MCP refusal includes
+the retained parent ID. Select complete detail, or inspect one method rather
+than a whole class, when the requested summary does not fit.
+
+The mapping path must be absolute. Selectors still take the observed names, such as
+`a.b`, and observed rows are unchanged. The result adds one `mapping` block with
+the file's path, SHA-256 and size, the header values the file reports
+(`compiler`, `compiler_version`, `min_api`, `map_version`, `pg_map_id`,
+`pg_map_hash`), valid record counts and up to 16 malformed line samples. Its
+`symbols` list has one entry per observed class, inner class, method and field;
+`inspect_android_method` lists the class and the selected method. `coverage`
+counts each resolution status. With summary delivery, these unchanged facts are
+under the view's `summary` field; the view separately reports source coverage.
+
+Lookups use the bridge's raw DEX names, not JADX display aliases such as a
+renamed reserved word. Each symbol resolves as:
+
+- `mapped`: exactly one record matches. A class needs one record for its raw
+  name (`verified_by: "class"`). A method must also match its DEX prototype
+  (`"descriptor"`) and a field its DEX type (`"type"`). R8 residual signature
+  metadata is used when present; otherwise original types are translated
+  through the file's class records.
+- `ambiguous`: `multiple-records`, `descriptor-mismatch`, `type-mismatch`,
+  `ambiguous-class` or `residual-signature-conflict`, with `candidate_count` and
+  up to 8 candidates. Conflicting residual metadata never selects a winner. A name match
+  whose prototype or type does not verify is never reported as mapped.
+- `unmapped`: no valid record matched the raw identity.
+- `unknown` with reason `projection-budget`: this claim did not fit the combined
+  reply budget. The observed raw symbol remains present; `coverage.unknown`
+  counts these omissions. Inspect that specific class or method separately,
+  or consult the selected local mapping file for complete source records.
+
+A line continues an inline frame stack when it repeats the previous line's
+minified range and obfuscated name and gives a single call-site line, such as
+`:7`. Only the outermost original of a stack becomes a candidate. Original
+line numbers and source files are not projected. Malformed records are counted
+and skipped, so an `unmapped` symbol might be described by one of them. A file
+that is missing, not a regular file, not UTF-8, larger than the byte limit or
+without any class record, such as `usage.txt` or `seeds.txt`, is refused before
+JADX is used. Requests read their mappings one at a time, in the same queue as
+the JADX work and under the same operation deadline. A mapping failure therefore never starts or retires the JADX
+session, and a different mapping reuses the loaded APK.
+
+## Link native declarations to JNI candidates
+
+When advertised, `inspect_android_jni_bindings` links original `ACC_NATIVE`
+declarations from standard root `classes*.dex` members to bundled ELF libraries.
+The supplied JAR's DEX reader preserves duplicate declarations before decompiler
+deduplication. This operation does not load the APK into the decompiler.
+MCP defaults to retained summary delivery when `detail` is omitted; select
+`complete` explicitly to receive the full report inline.
+
+```json
+{
+  "path": "/absolute/Example.apk",
+  "class_name": "org.conscrypt.NativeCrypto",
+  "method_names": ["EVP_PKEY_new_RSA"],
+  "abis": ["arm64-v8a"],
+  "detail": "summary"
+}
+```
+
+Class/method names and optional `descriptors` select raw DEX identities.
+`library_paths` selects exact logical APK paths such as
+`lib/arm64-v8a/libconscrypt_jni.so`; each library's `source_path` preserves its
+original ZIP spelling. Omitted filters include all scoped facts; `[]` matches
+none. Class selection never narrows the global inventory used for table-class
+attribution.
+
+Independent `declarations`, `libraries`, `candidates` and `bindings` collections
+have stable IDs and source ordinals. Candidates retain APK/library digests,
+ABI, function addresses and file offsets. Table candidates also retain section,
+table and entry identity plus all three name/signature/function pointer slots
+and their relocation sources. JNI exports follow the
+[UTF-16 escaping and short-before-long rules](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/design.html#resolving-native-method-names);
+failed escaping does not acquire an invented export match. Tables require
+NUL-terminated [Modified UTF-8 strings](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/types.html#modified-utf-8-strings),
+valid descriptors and executable load mappings. REL, RELA and RELR retain
+separate provenance; unsupported packed relocations and unresolved pointer
+spans stay explicit unknowns.
+
+A static `JNINativeMethod` entry names no class. Attribute it uniquely only
+when exactly one declaration in the complete recorded native inventory has
+that `(name, descriptor)` pair. Multiple classes remain ambiguous after a
+class filter; a partial inventory cannot establish unique attribution.
+
+Each selected declaration has a row per selected/observed ABI. `matched` means
+candidate presence was observed; `ambiguous` means multiple observed targets
+or class associations remain. Binding `coverage` is separate: a matched
+partial row does not establish complete uniqueness, and an empty partial scan
+is `unknown`, never `unmatched`. ELF/ABI label mismatches preserve facts without
+asserting a binding. No result establishes library loading, runtime registration
+or method invocation.
+
+Summary returns the first 64 selected binding rows, their declaration/candidate
+closure and every selected library's identity, coverage and failure reason;
+counts and page coverage describe the full selected binding set. Selected
+declaration IDs have separate preview coverage, so native declarations remain
+visible even when the APK has no bundled ABI libraries. Complete
+Evidence stays retained. Read exact fields or further pages without reopening
+files or rerunning analysis:
+
+```json
+{
+  "source": { "kind": "retained-evidence", "evidence_id": "ev_<digest>" },
+  "view": {
+    "kind": "android-jni",
+    "collection": "bindings",
+    "offset": 64,
+    "limit": 64,
+    "fields": ["declaration_id", "abi", "status", "coverage", "candidate_ids"]
+  }
+}
+```
+
+Collections also include `declarations`, `candidates` and `libraries`, with
+exact filters and batch lookup by declaration/candidate/library IDs. `row_index`
+is the original parent collection index; DEX and
+ZIP source ordinals stay separate. Complete detail returns the full report.
+CLI uses the same selection and delivery contracts. Its common one-shot
+default remains complete; summary delivery requires an explicit Evidence path:
+
+```sh
+rea inspect-android-jni-bindings /absolute/Example.apk \
+  --query '{"class_name":"org.conscrypt.NativeCrypto","method_names":["EVP_PKEY_new_RSA"],"abis":["arm64-v8a"]}' \
+  --detail summary --evidence_output /absolute/fresh-jni-evidence.json
+```
+
+Optional `--view` accepts the same JSON page and requires summary delivery.
+Evidence bundles never overwrite files. Complete declarations and one library
+selection are cached within the immutable APK session. Changing ABI/library
+selection replaces the scan; class/method selection reuses it. Fresh analysis
+still validates current caller APK bytes. Idle/close releases the caches;
+retained Evidence remains historical and independently readable.
+
 ## Interpret the result

 - Package inspection retains decoded manifest XML, summary declarations,
@@ -266,6 +480,11 @@ the same source byte limit and explicit truncation reporting.
  `dex_descriptor`, for example `(I)V`. Display names can be JADX aliases;
  the descriptor alone is not a complete raw DEX method ID. Overload indices
  are tied to this artifact and engine, not stable identities across builds.
+- A `mapping` block appears only when the caller selected `mapping_path`. Its
+  names are claims from that file, not observations of the APK. REA does not
+  check that the mapping belongs to this build; `pg_map_id` is reported, not
+  compared. Evidence keeps the selected path in its parameters and the file's
+  SHA-256 in the result.
 - Method inspection reports Java or smali, fallback markers and complete/partial
  returned text. Decompiled source is a derived representation. A complete text
  result does not establish complete semantics or a byte-identical reconstruction.
@@ -355,6 +574,19 @@ target/configuration changes, failure, timeout, cancellation, MCP disconnect or
 server shutdown. One-shot CLI commands always join cleanup before returning.
 REA never writes to the original APK or launches target code.

+JNI scans reuse the analyzer process without loading the APK into the
+decompiler. They admit at most 64 MiB per DEX member and 256 MiB of DEX bytes,
+with a 4 MiB native-declaration JSON allowance before MCP string escaping.
+Native libraries are processed sequentially: one 64 MiB buffer, 256 MiB total
+selected read work, and a 16 MiB parsed-library-facts allowance. ZIP inventory
+and library counts also have explicit resource bounds. Unexamined occurrences
+remain unknown. A complete relationship report has a separate 16 MiB serialized
+allowance; summaries/pages allow 1 MiB including their provenance envelope.
+These are resource admissions, not claims about maximum valid Android formats.
+Select fewer ABI/library occurrences or smaller retained pages when needed.
+Completed parsed library facts survive failed reader finalization in typed
+partial observations; the exact reader owner remains available for cleanup retry.
+
 On Windows, stdin writes preserve stream backpressure and run outside the Node
 event loop. Cancellation terminates the retained job, including descendants,
 before workspace cleanup. On Windows, a detached REA helper owns the private
@@ -440,6 +672,27 @@ complete, case-sensitive search contract. A protocol frame above **8 MiB**, or c
 **32 MiB per operation**, fails with a diagnostic instead of returning an incomplete inventory
 as complete. These are memory-safety boundaries, not undocumented result caps.

+A selected R8/ProGuard mapping is re-read and SHA-256 checked on every call, up
+to **64 MiB**. The serialized provider keeps one successful parsed index, keyed
+by byte length and digest with fixed parser options. Identical bytes reuse that
+index; changed bytes are reparsed, missing files still fail, and each response
+preserves the currently selected path. The index is released on provider idle
+retirement or close. Omitting `mapping_path` never applies the cached mapping.
+During replacement, the old index can coexist with the new parse until it
+succeeds; these transient allocations count toward process memory.
+
+Before retaining records, the parser admits an estimated **128 MiB** index
+representation and **8 MiB** of expanded mapped claims per residual class,
+including shared header facts. The index allowance accounts for strings and
+containers; it is not a measured V8 heap cap. Parameter and metadata expansion
+is admitted before splitting or JSON decoding. These fixed resource bounds
+have no runtime override; refusal reports `resource_constraint`, the source
+line and mapping SHA-256. Ambiguous lookups count all candidates while keeping
+only the first eight in stable file order. A separate **8 MiB** combined claim
+budget applies to the actual query set, including outer and inner classes,
+before cloning the report. Claims that do not fit become explicit `unknown`
+entries; other admitted claims and all observed identities remain available.
+
 ## Real verification

 Download the explicit public fixtures once; this installs no tools:
@@ -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`.

@@ -239,6 +244,13 @@ serialized size of the report together with its limitations (which repeat
 archive names) is then checked against an 8 MiB output budget (the exact check
 is authoritative); an over-budget report is refused, not truncated.

+Signing blocks admit at most 4096 ID/value pairs; at most 4096 signing-relevant
+META-INF entries are retained. These fixed counts, signer/lineage counts and the
+report byte budget return nonretryable `resource_constraint` errors naming the
+effective allowance. This release has no runtime override for them. Waiting for
+an active scan cannot raise a fixed count, and complete CLI JSON cannot raise the
+report budget. Occupied scan-queue capacity remains retryable after a scan finishes.
+
 The whole-file reader allocates the selected snapshot and bounded read scratch;
 total process memory exceeds the selected file's size. It also computes the complete
 file SHA-256, so inspection is not header-only. Content digests are recomputed
@@ -100,12 +100,13 @@ still suppresses all string projection, including in this mode.
 - **Metadata comes from apktool.yml as apktool printed it.** Version codes
  keep their own spelling (`'7'` versus `7`); `package_name` is read from
  the decoded manifest, not inferred.
-  Apktool 3's emitted `version: 3.x.y` header selects its single-line string
-  dialect: literal hashes, single quotes, empty strings, and the text `null`
-  stay part of the value; producer backslashes and Unicode escapes decode
-  once. Older/tagged documents retain YAML scalar semantics; double-quoted
-  values also retain YAML string semantics.
+  The `version: 2.9.0`-or-later header that Apktool 2.9+ and 3 emit selects
+  their single-line string dialect: literal hashes, single quotes, empty
+  strings, and the text `null` stay part of the value; producer backslashes
+  and Unicode escapes decode once. Older/tagged documents retain YAML scalar
+  semantics; double-quoted values also retain YAML string semantics.
  This distinction follows the released
+  [2.9.0 metadata writer](https://github.com/iBotPeaches/Apktool/blob/b64e257c9b689eb9630ad0241f2fe4f4a749955b/brut.apktool/apktool-lib/src/main/java/brut/androlib/apk/VersionInfo.java#L38-L42),
  [3.0.3 metadata writer](https://github.com/iBotPeaches/Apktool/blob/18b5e99cb56ff9451e8aa55b065dcf5bbd616975/brut.apktool/apktool-lib/src/main/java/brut/androlib/meta/VersionInfo.java#L49-L55)
  and [string escape owner](https://github.com/iBotPeaches/Apktool/blob/18b5e99cb56ff9451e8aa55b065dcf5bbd616975/brut.j.yaml/src/main/java/brut/yaml/YamlStringEscapeUtils.java#L55-L116).
 - **The manifest is the decoded text**, bounded at 512 KiB and reported as
@@ -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.
@@ -21,14 +21,14 @@ graph TD
    subgraph "Application Layer"
        APP["src/application/<br/>Shared CLI/MCP workflows<br/>enhanced analysis and investigations"]
        SESSION["SessionProviderRouter + BinarySession<br/>one immutable deep binding per target<br/>disjoint auxiliary routing"]
-        REGISTRY["AnalysisProviderRegistry<br/>sorted deep candidates<br/>deterministic selection, no fallback"]
+        REGISTRY["AnalysisProviderRegistry<br/>sorted deep candidates<br/>deterministic selection, no fallback<br/>ProviderInspectionScope: prerequisite observation lifetime"]
        RECORDS["src/application/investigation/<br/>composed InvestigationRecords + narrow ports<br/>EvidenceLedger and Unknown ownership"]
        SNAPSHOT["BinarySessionRecords + AnalysisSnapshotCache<br/>binary target/profile snapshots and session file ownership<br/>record coordination and post-commit notifications"]
        JS_RECON["src/application/javascript/ + src/artifacts/javascript/<br/>JavaScript artifact reconstruction<br/>directory/ASAR reads<br/>AST-only bundle projection"]
    end

    subgraph "Provider Layers (selected adapters)"
-        PROVIDER_OWNERS["src/providers/<br/>shared deferred client and inspection owners<br/>exact cleanup retry and attributed failures"]
+        PROVIDER_OWNERS["src/providers/<br/>shared deferred client owners<br/>exact cleanup retry and attributed failures"]
        PWNTOOLS["src/native/pwntools/ + src/native/pwndbg/<br/>BYO offline ELF/core adapters<br/>owned snapshots/Python and optional core-only GDB<br/>unchanged upstream parsers, ABI structures and mapping API"]
        WASM["src/wasm/<br/>caller-supplied WABT; immutable artifact inspection<br/>owned process supervision and retryable workspace cleanup"]
        APKSIG["src/apkSignature/<br/>in-process APK Signing Block + v1 reader<br/>bounded single read, no device or execution"]
@@ -75,7 +75,7 @@ graph TD
    end

    subgraph "Domain Layer"
-        DOMAIN["src/domain/<br/>Pure side-effect-free modules<br/>format declarations, Evidence, comparisons, application graphs"]
+        DOMAIN["src/domain/<br/>Pure side-effect-free modules<br/>format declarations, provider selection, Evidence, comparisons, application graphs"]
    end

    subgraph "Configuration"
@@ -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
@@ -415,7 +431,8 @@ allowance; exhaustion fails the observation explicitly instead of guessing scope
 Response metadata parses repeated CDP header field lines independently. The
 Link projection retains their declarations in order. `csp.directives` lists the
 directives of every CSP policy in order, across field lines and comma-separated
-policies, without recording policy boundaries, so a directive name can repeat.
+policies, without recording policy boundaries, so a directive name can repeat
+across policies. As in CSP3, a repeated name within one policy is ignored.
 Single-valued policy fields combine their lines as one comma-separated value,
 as RFC 9110 specifies. Each link keeps its target in `href` and
 its relationship context in `context_url` with a separate `context_scope`;
@@ -448,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.
@@ -51,6 +51,30 @@ covers endpoint discovery only. The following WebSocket handshake and
 `Target.attachToTarget` each use `command_timeout_ms`. `capture.limits` controls retained event and network-content
 budgets; it does not change those liveness deadlines.

+## Validate a scenario before running it
+
+`validate-browser-scenario INPUT_JSON` checks one scenario against the same
+`browserScenarioSchema` refinement that `capture_browser_scenario` admits, and
+stops there. `INPUT_JSON` may be inline JSON, a JSON file path, or `-` for
+standard input.
+
+```bash
+rea validate-browser-scenario ./browser-scenario.json --json
+```
+
+A valid scenario reports `{"valid":true,"actions":<count>,"secrets":<count>}`
+and exits 0. An invalid one exits 1 and reports the same field paths capture
+would report, so a correction made here is the correction capture needs:
+duplicate or reserved step IDs, duplicate secret identities and
+environment-variable names, undeclared secret references, request-step
+violations, and unknown fields.
+
+Validation performs no browser discovery, launch, attachment, or navigation and
+constructs no provider. It does not read secret environment variables, so a
+scenario whose declared variables are unset still validates; the missing-value
+failure belongs to capture. A schema-valid scenario does not prove that the
+executable or target is available on the host.
+
 ## Minimal launch example

 Save this as `browser-scenario.json`, replacing the executable path with an
@@ -173,6 +197,12 @@ distinction: it closes and deletes provider-owned profiles, but only disconnects
 from an external CDP browser. Real-browser verification checks both outcomes and
 confirms that an attached external browser remains alive.

+CDP connections leave Playwright's default-context overrides disabled. The
+selected page receives the declared scenario environment and temporary focus
+emulation, so actions can complete while that page is in the background.
+Its environment owner clears these overrides before disconnecting; other pages
+keep their media settings. Connecting does not create a bootstrap page.
+
 That cleanup requires REA to remain running. Abrupt termination, including
 Windows process-tree termination or POSIX `SIGKILL`, can leave the launch
 profile and Playwright artifacts behind. A profile can retain cookies, history,
@@ -207,7 +237,8 @@ HTTP(S) URLs may include ordinary query values and fragments directly. Use
 ordered structured query entries when a value needs to reference a declared
 environment-backed secret. Form, storage, and cookie values are either literal
 strings or declared secret references; request step headers can also read a
-cookie or local storage value from the page. Raw URL userinfo credentials are rejected.
+cookie or local storage value from the page, and request steps and `goto`
+destinations can send [saved values](#saved-values). Raw URL userinfo credentials are rejected.
 Captured credential-header
 values are not retained, and declared secret values are redacted automatically.
 A secret may be declared solely to
@@ -380,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
@@ -400,6 +433,17 @@ data you may change. This scenario creates one item:
  by default) get smaller: after a 32-character `X-CSRFToken` value, a body over
  about 47 KiB is kept as `unavailable`. Raise `capture.limits` when the
  application's responses are larger.
+- A header can send Basic credentials, `{"source": "basic_credentials", "parts":
+  [username, password]}`: the base64 of `username:password`, after a `prefix`
+  such as `"Basic "` or with none, as some APIs take encoded credentials in
+  their own header. Each part is a literal, a declared secret, a saved value, a
+  cookie or a local storage entry, so a header a frontend builds from a login
+  token can be sent too; the password is never a literal other than empty, since
+  Evidence records literals as written, and a username with a colon fails the
+  step, since Basic authentication ends the username at its first colon. The
+  encoded value is redacted however short, as
+  `[REDACTED:page:<step_id>.<header>]`, and parts read from the page are
+  redacted as page values are.
 - Validation refuses a header name given twice in a step, header names a
  page's `fetch` cannot set, such as `Cookie`, `Origin`, `Host` or `Sec-*`, and
  `User-Agent`, which Chrome drops; it refuses line breaks and other ASCII
@@ -425,6 +469,143 @@ Captures with request steps state in `limitations` that the steps sent their
 declared requests through the page's fetch. A scenario without request steps
 is unchanged.

+## Saved values
+
+A step can keep a string or number from a JSON response, by name, and a later
+step can send it, so a scenario can read back, edit and delete an object whose
+id the application assigns:
+
+```json
+{
+  "browser": {
+    "mode": "launch",
+    "executable_path": "/absolute/path/to/chromium"
+  },
+  "start_url": { "url": "http://127.0.0.1:3000/items" },
+  "actions": [
+    {
+      "step_id": "save-item-1",
+      "action": "click",
+      "timeout_ms": 10000,
+      "locator": { "kind": "role", "role": "button", "name": "Save" },
+      "save_response": {
+        "method": "POST",
+        "path": "/api/items",
+        "save": [{ "name": "item_1", "json_pointer": "/id" }]
+      }
+    },
+    {
+      "step_id": "open-item-1",
+      "action": "goto",
+      "timeout_ms": 10000,
+      "destination": { "url": "http://127.0.0.1:3000/items/{saved:item_1}" },
+      "wait_until": "load"
+    },
+    {
+      "step_id": "copy-item-1",
+      "action": "request",
+      "timeout_ms": 10000,
+      "method": "POST",
+      "path": "/api/items/{saved:item_1}/copies",
+      "json": {
+        "source_id": "{saved:item_1}",
+        "title": "Copy of {saved:item_1}"
+      },
+      "expected_status": [201]
+    }
+  ]
+}
+```
+
+- A `request` step saves with `save: [{name, json_pointer, secret}]`, from its
+  own response. A `click` or `press` step saves with `save_response: {method,
+  path, save}`, from a newly observed matching response while the step waits.
+  The recorder watches before the action and excludes requests already running,
+  such as an earlier autosave. Method/path matching does not prove that the UI
+  caused the request: use a path that distinguishes the intended operation from
+  background polling. Multiple observed matches before binding fail as ambiguous;
+  requests starting after this observation window cannot be ruled out. It matches the method and a path on the
+  start origin as the browser spells it, so a path may name `My List` or
+  `My%20List` (`{*}` matches one segment, and the query is ignored), and fails
+  the step unless a 2xx JSON response arrives before its `timeout_ms`; one still
+  being read when the step times out or is cancelled saves nothing. A pointer
+  that names no string or number fails the step, so later steps never send a
+  missing value, as does a response over 4,000,000 characters: a request step
+  stops reading and aborts its fetch there. A UI step reads a body only when
+  its decoded size is bounded at 12,000,000 bytes or less: its received size,
+  or the declared Content-Length of one served from cache, times 1032 for each
+  gzip or deflate coding, the most DEFLATE expands. Other codings and unknown
+  or zero sizes are refused before materializing the body; decoded text over
+  the character limit also fails. The UI action may already have applied.
+- `{saved:name}` sends a saved value in a request step's `path`, including its
+  query, and in a `goto` destination's `url`, percent-encoded; a destination's
+  structured `query` values are sent as declared. A saved value that makes a
+  path segment `.` or `..`, alone or with the text beside it (including `%2e`),
+  fails the step, since the URL would drop it. In a request step's `json` body,
+  a string that is only `{saved:name}` becomes the saved value with the JSON
+  type it was saved with, so a saved number id is sent as a number, and
+  `{saved:name}` inside a longer string is filled as text. A header value or
+  Basic credentials part sends one as `{"source": "saved", "name"}`. Other
+  braces, such as `{id}`, are sent as written, and so is a percent-encoded
+  `%7Bsaved:name%7D` anywhere but a `goto` URL, whose parsed form spells the
+  braces that way.
+- Validation refuses a saved value that no earlier step saves. A later save of
+  the same name replaces the value. An integer past 2^53, which JSON parsing
+  would round to another number, and a number that is not finite, such as
+  `1e400`, negative zero, or a value that underflows to zero, such as `1e-400`, fail the step
+  that saves it.
+- A scenario keeps at most 4,000,000 characters of saved values at once,
+  counting distinct retained redaction spellings, including trimmed variants,
+  of values saved as secret. Replacing a binding releases its live value
+  charge, while secret spellings remain protected for the scenario lifetime.
+  A save past the budget fails before changing the binding.
+- A value saved with `secret: true` is redacted however short, as a declared
+  secret is, as `[REDACTED:page:<step_id>.<name>]`. The selected source
+  response is protected before retaining its body or header values, including
+  when only headers were requested. If that body cannot be read safely, its
+  body and header values remain unavailable. Before publishing the capture,
+  the selected source transaction's earlier URL, request headers and request
+  body are also protected using the admitted values. Unresolved source values
+  withhold that transaction's affected metadata/content with an explicit
+  limitation. Before publication, retained events are rechecked
+  with the final marked-response values, including immediate follow-up requests
+  and their response bodies, console/page errors, WebSocket text and event URL/name fields. Learned redaction facts are independent of source-identity readiness. Unknown source values withhold only the selected
+  source transaction. Other saved values, such as ids, stay visible, since
+  environments model them. The environment build warns about saved values
+  named like credentials that are not marked secret
+  (`credential-named-saved-values`).
+- Page-derived cookie/local-storage values and constructed Basic credentials
+  remain redacted only from observations made after they were read/built.
+  They do not retroactively rewrite earlier facts. The final event projection
+  borrows only declared and response-marked patterns; promotion of an already
+  held page value to an explicit response secret preserves its first marker.
+  Projection state is session-local, references admitted pattern/byte owners,
+  and is invalidated on admission or response classification changes.
+- Screenshots are withheld as `missing` from the start when the scenario plans
+  any response save marked `secret: true`, page-derived or Basic authentication
+  header values, or whenever nonempty sensitive values
+  are already known. Raw pixels cannot be safely text-redacted, so the provider
+  does not request pixels in those cases. This also protects earlier steps and
+  partial failures without retaining an image to scrub later. Other requested
+  artifacts remain available; affected screenshot/aggregate completeness is
+  partial and is not eligible for equality.
+- Saved URLs and expanded request JSON are admitted before building their expanded strings or
+  serializing. Its allowance is the smaller of Node's string limit and
+  one sixteenth of current V8 available heap bytes, allowing for the expanded
+  tree, serialization, Playwright transport and browser-side copies. Size
+  accounting includes JSON escaping and repeated references; each distinct
+  saved value's size is measured once per request. An oversized request fails
+  before browser dispatch; the complete request envelope, including repeated
+  header values, is checked as well. URL encoding uses a conservative
+  nine-characters-per-UTF-16-unit allowance before encoding a saved value.
+  Reduce the payload/repetitions, or raise the parent
+  Node heap and restart; this is a conservative allocation estimate, not a
+  measurement or guarantee of browser/process-family memory.
+- Evidence records a request step's empty `save` list as absent, so a scenario
+  that saves nothing records the same parameters and `scenario_sha256` as
+  before saved values existed, and REA versions without saved values read its
+  captures.
+
 ## Network evidence

 `capture.events: ["network"]` retains request, response, completion, failure,
@@ -472,8 +653,9 @@ the browser's wall-clock start, and `elapsed_ms`, its time from that start to
 the end of the response, when the browser reports them. The environment views
 time scenario records from these, as HAR entries are timed: the browser's start
 where it reported one, else `observed_at`, which trails it by up to tens of
-milliseconds while REA reads other responses, and a duration of 0 where the
-browser reported none. Captures made before these fields existed lack them and
+milliseconds while REA reads other responses. A duration is retained only from a
+unique terminal event that reports it; missing or ambiguous durations stay
+omitted, while an explicitly reported zero remains zero. Captures made before these fields existed lack them and
 are read in record order. REA versions before them refuse captures that carry
 them. Scenario comparisons ignore all three (`ignore_network_request_timing`).
 Requests sharing a URL remain distinct. Redirects link to the preceding
@@ -621,3 +803,58 @@ rules and preserve the same missing fact.
 Network normalization also commits the removal of capture-local transaction IDs,
 attribution to the requesting step, and unordered transaction comparison. These
 built-in rule identities participate in the normalization digest.
+
+## Summary delivery and retained views
+
+`capture_browser_scenario` accepts `detail: "summary"` to retain the complete
+capture in the MCP session and return its summary. The default remains
+`complete`. Delivery detail does not change scenario parameters or identity.
+
+The summary reports each step's status, error, URL and captured/missing/truncated
+section names. It omits `not_requested` sections and repeated `before_url` values.
+The accessibility tree comes from the first unsuccessful step, or the final
+step on success; when that step captured no tree, its nearest earlier captured
+tree is identified explicitly. Event and network counts cover retained records,
+with capture omissions reported separately.
+
+For the one-shot CLI, save the complete Evidence before selecting a summary:
+
+```bash
+rea capture-browser-scenario scenario.json --detail summary --evidence_output /absolute/path/scenario-evidence.json --json
+```
+
+Use the returned `normalized_result.parent_evidence_id` with
+`inspect_analysis_view` source `{kind: "retained-evidence", evidence_id: "..."}`.
+For a CLI bundle, use an `evidence-file` source with its absolute path and the
+parent Evidence ID. Views read the recorded capture; they never replay actions.
+
+- `{kind: "summary"}` returns the same overview.
+- `{kind: "browser-scenario", collection: "steps", step_indices: [2], artifacts: ["accessibility"], offset: 0, limit: 1}` returns selected recorded steps and artifacts.
+- `{kind: "browser-scenario", collection: "events", event_kinds: ["response"], transaction_ids: ["request-2"], offset: 0, limit: 20}` pages selected events with original item indices.
+
+Omitted filters select all; empty arrays select none. Pagination counts matching
+retained rows. Exhausting a page does not establish capture completeness or
+current application state.
+
+Transaction pages use `{kind: "browser-scenario", collection: "transactions", limit: 20}`.
+Their stable identity is the parent Evidence ID plus `transaction_id`; each row
+keeps original event indices. Metadata events are returned by default. Select
+`event_kinds: ["network-content"]` for recorded bodies and header values, or
+`event_kinds: []` for identity and indices alone. A `step_indices` filter selects
+a whole transaction when any retained event belongs to a selected step; this
+is receipt attribution, not proof that the action caused the request.
+
+For a large retained tree, request `{kind: "browser-scenario", collection: "text",
+step_index: 10, artifact: "accessibility", offset: 0, limit: 2048}`. `dom` is also
+supported. Offsets and limits count UTF-16 code units. The full artifact digest
+and byte size remain attached to each page. Missing, truncated and unrequested
+text stay explicit; source truncation counts are preserved without treating an
+exhausted page as a complete capture.
+
+Network summary counts include every retained transaction identity, including
+those whose request event was dropped. Missing request events, conflicting
+metadata and observed request failures have separate counts. `transactions` is
+`null` when network observation was unrequested or its legacy selection is
+unknown and there are no retained transactions; an observed empty inventory is
+`0`. Full capture omissions remain available and each page carries source
+completeness, dropped-event counts and omitted-transaction accounting.
@@ -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).
@@ -51,6 +51,15 @@ module page. See
 [JavaScript application workflows](javascript-application-workflows.md) for
 views, feature traces and comparisons that take the same saved Evidence.

+Add `--timings` to a command to write one JSON timing record to stderr. For
+example, `rea inspect-elf-notes program --json --timings > result.json` keeps
+stdout as a parseable result and writes
+`{"rea_timings":{"version":1,"command_ms":42}}` to stderr. `command_ms`
+measures CLI command dispatch and result delivery; it is not provider-only or
+analysis-only time. The flag is off by default, and the record omits stages
+that REA did not measure. Root version reporting does not dispatch a command
+and has no command timing record.
+
 ## JSON Lines record output

 Use `--format jsonl` to consume row-oriented results one record per line:
@@ -73,9 +82,14 @@ arbitrary nested graph array.
 A top-level array emits its elements in source order. An object must have one
 clear `rows`, `items`, `records`, or `occurrences` array, directly or under
 `page`. Evidence uses the same boundaries inside `normalized_result`.
-An arbitrary report or a scalar selection is refused with an actionable error;
-use `--format json` for a complete document. If several collections exist,
-select one with `--filter-output`, for example `normalized_result.rows`.
+Any other selection is refused before a record is written, including an
+arbitrary report, a scalar, a nested array elsewhere, and a columnar object such
+as the `inspect-sqlite-database --table` `normalized_result.rows`
+(`{columns, values}`). The refusal is the caller error `invalid_request`
+(`invalid_input`) and names the selection and its observed shape; the analysis
+itself succeeded, so use `--format json` for the complete document. If several
+collections exist, select one with `--filter-output`, for example
+`normalized_result.rows` for an analysis view.

 Object collections finish with a control record:

@@ -151,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;
@@ -236,6 +259,28 @@ Formats 2, 3 and 4 retain header, directory and integrity facts. Compact deliver
 keeps complete Evidence in the requested bundle. See [Godot PCK](godot-pck.md)
 for embedded packs, batch queries and unknown encrypted coverage.

+Inspect a UnityFS AssetBundle without running Unity:
+
+```sh
+rea inspect-artifact content.bundle --detail summary --evidence_output evidence.json --json
+rea extract-artifact content.bundle --json
+```
+
+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 a Node.js SEA carrier without running it:

 ```sh
@@ -246,6 +291,42 @@ rea extract-artifact ./application --json
 See [Node.js SEA](node-sea.md) for supported layouts, script and asset paths,
 fuse observations, and the real-fixture verification lane.

+Inventory and extract Intel HEX or S-record regions:
+
+```sh
+rea inspect-artifact ./firmware.hex --json
+rea extract-artifact ./firmware.hex --json
+```
+
+See [Intel HEX and S-record images](hex-records.md) for recognition, region
+names, metadata and limits.
+
+Inspect and extract stored U-Boot legacy uImage payloads and components:
+
+```sh
+rea inspect-artifact ./firmware.bin --detail summary --evidence_output firmware.json --json
+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 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
@@ -438,7 +519,13 @@ The selected provider remains bound to the session until an explicit switch
 or close. Provider failures are returned with their original reason. For an
 `ambiguous` selection error, choose from `details.candidate_ids`; for
 `provider_unavailable`, follow `message`, `remediation.action`, and the original
-reasons in `details.rejections`. For Hopper, Ghidra, IDA, JADX, and Kuna, run
+reasons in `details.rejections`. Each rejection names its `origin`: `availability`
+entries describe local readiness failures, including missing configuration or an
+invalid existing registration; they do not establish target support. `target`
+entries record a refused kind, format, architecture, or role. An availability-only
+message describes the recorded rejections without claiming that every provider
+is unconfigured or that target support is known.
+For Hopper, Ghidra, IDA, JADX, and Kuna, run
 `rea doctor --provider ID --json` to diagnose the selected engine. Other adapters,
 such as `pwntools-elf`, report their configuration requirements directly and are
 not accepted by `doctor --provider`. See
@@ -480,6 +567,11 @@ Dispatching a provider metadata write invalidates the active session's snapshot
 even if its reply fails: the provider may already have applied the write.
 Close and reopen the target before importing or saving another snapshot.

+Saved snapshots include only cache entries whose subject identifies the selected
+target. Unbound observations and observations of child artifacts remain available
+in the open session and its Evidence bundle; they are excluded from the target's
+saved replay entries without changing their subjects.
+
 Snapshots retain eligible target-scoped question histories in full, including
 mutation Evidence recorded while another target was active. Observations and
 related questions must still belong to the saved target. If those dependencies
@@ -535,6 +627,14 @@ rea compare /absolute/path/to/evidence/left.json /absolute/path/to/evidence/righ
 rea compare left.json right.json --record_pairs '[{"left_evidence_id":"ev_<left-sha256>","right_evidence_id":"ev_<right-sha256>"}]' --json
 ```

+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
@@ -558,6 +658,24 @@ 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.

+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 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

 Historical source inventories preserve exact filenames, including literal backslashes
@@ -733,8 +851,18 @@ 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. The bound URL is written to stderr as
-one JSON log line (`"msg":"MCP transport listening"`) whatever `REA_LOG_LEVEL`
+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:
+
+```sh
+rea mcp --http --host 0.0.0.0 --allowed-hosts 127.0.0.1,rea.lan
+```
+
+Requests with a different `Host` or browser `Origin` receive `403`; a missing
+`Origin` is accepted. The announced client URL uses the bound hostname when
+admitted, otherwise the first declared hostname, with the actual bound port.
+It is written to stderr as one JSON log line (`"msg":"MCP transport listening"`) whatever `REA_LOG_LEVEL`
 is set to; nothing is written to stdout. `rea mcp --http --help` lists the accepted options. The listener serves
 one client at a time: a session ends with the client's `DELETE`, and a client
 that connects while another session is open takes it over, so a client that
@@ -772,9 +900,18 @@ rea environment-serve manifest.json --evidence capture.json --port 8765
 ```

 `--host` and `--port` resolve like `rea mcp --http`: flags, then `MCP_HOST` and
-`MCP_PORT`, then `127.0.0.1` and an ephemeral port. `ENVIRONMENT_NAME` renames
+`MCP_PORT`, then `127.0.0.1` and an ephemeral port. A non-loopback bind requires
+`MCP_ALLOWED_HOSTS` with the same hostname rules and Host/Origin gates as above.
+`environment-serve` uses this environment setting; `--allowed-hosts` belongs to
+`rea mcp --http`. For example:
+
+```sh
+MCP_ALLOWED_HOSTS=127.0.0.1,rea.lan rea environment-serve manifest.json --evidence capture.json --host 0.0.0.0
+```
+
+`ENVIRONMENT_NAME` renames
 the served environment; set but blank, it is refused as `configuration_invalid`
-like a blank `MCP_HOST`. The bound URL is written to stderr as one JSON log line
+like a blank `MCP_HOST`. The admitted client URL is written to stderr as one JSON log line
 (`"msg":"MCP transport listening"`). See
 [agent environments](agent-environments.md) for what the state and replay
 return and do not establish.
@@ -921,8 +1058,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
@@ -934,6 +1071,42 @@ 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:
+
+```bash
+rea inspect-analysis-view request.json --format csv \
+  --filter-output normalized_result.rows --columns name,address
+```
+
+The first line is a REA metadata record,
+`# rea-delimited-v1 <JSON>`. It carries the selected path, view request, limitations and unknowns,
+coverage, source coverage and completeness, command, and duration. A metadata
+value of `null` means that the selected row collection did not provide that
+fact; it does not mean complete coverage. The following line is the header.
+CSV records use CRLF line endings; TSV records use LF. Cells containing the
+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; 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
+select exactly one row array, a row is not an object, or a selected cell is
+nested or formula-leading. JSON remains the complete canonical output; use it
+to retain fields outside the selected columns or preserve exact formula-leading
+text. Token counting and token windows are not
+available for CSV/TSV because slicing would corrupt records or metadata.
+
 `--filter-output` selects fields from successful command data. Classified failures
 retain their complete typed diagnostic projection even when the selector matches
 a field such as `code` or `message`, or names a missing field. `--full-output`
@@ -952,10 +1125,10 @@ Cutter when available. This is separate from `--format json`, which selects the
 CLI result representation; the global `--json` flag selects that same CLI
 representation.

-Cutter still accepts deprecated `--json=true` and `--json=false` compatibility
-values. When both forms are present, `--json-output` takes precedence in either
-argument order. Bare `--json` retains its global meaning of selecting JSON CLI
-output formatting.
+Cutter no longer accepts command-local `--json=true` or `--json=false`.
+Replace these with `--json-output=true` or `--json-output=false`, respectively.
+Combine `--json-output` with bare `--json` when both Cutter command output and
+the CLI result should use JSON; either argument order is accepted.

 | Status    | Meaning                                                                                                                                                                                                                                                                                                                                                                                |
 | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -1083,3 +1256,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.
@@ -6,6 +6,45 @@ for the reviewed setup transaction and [client IDs](installation.md#supported-ag
 The versioned verification notes below describe their stated runs; live service
 acceptance is verified only where explicitly recorded.

+## Launchers and PATH
+
+A client launched from a desktop app, IDE or service can inherit a different
+`PATH` from your terminal. An absolute path to `rea-agents` does not resolve its
+interpreter: the npm launcher's `#!/usr/bin/env node` still searches `PATH` for
+Node. Running that command successfully in a terminal does not establish that
+the client can launch it.
+
+For JavaScript installations, setup registers the selected runtime
+executable and REA script by absolute path. On POSIX, it prefers executable
+`node` or `bun` and REA aliases on setup's `PATH` only when they resolve to the
+same selected files. This preserves manager-owned aliases across version updates;
+otherwise setup uses the selected paths directly. This also applies when setup
+runs through a package runner: retain the selected cache entry and runtime while
+the registration uses them. Clearing either makes startup fail without resolving
+another package from the client's project. Restore the same installation before
+repairing it; an unidentified registration remains untouched. See
+[installation and recovery](installation.md#package-runners-and-global-installation).
+Setup does not copy your ambient environment into client
+settings. To refresh an older registration, preview
+`rea setup --client <client-id> --skill=false --dry-run`, then run the same command
+without `--dry-run` and approve the displayed changes. Setup preserves unrelated
+settings, backs up changed configuration and leaves an aligned registration
+unchanged. Restart the client after applying the update.
+
+If a runtime manager removes the registered executable and no surviving alias
+was available, doctor reports its identity as unknown and setup retains the
+registration. REA does not infer that an arbitrary missing executable was Node
+from its script argument. Back up the client's configuration, verify the absolute
+path and supported version of the runtime you intend to use, then update only
+the runtime command, preserving the REA script arguments and other settings.
+Rerun setup to review the registration and restart the client.
+
+`rea mcp doctor --json` tests the production MCP adapter using the runtime
+executable and environment of the terminal running doctor. It does not launch
+the client's configured command or reproduce the client's environment. If doctor
+passes but the client disconnects, inspect the client's startup error and registered
+launcher; see [verification scope](client-verification.md#launch-environment-verification).
+
 ## Runtime settings and client deadlines

 `update_analysis_settings` changes curated defaults inside the running REA
@@ -40,6 +79,17 @@ Connect Fiddler Everywhere's MCP server separately for HTTP traffic debugging,
 preserving your REA client entry. See the
 [setup instructions and public skills](web-network-captures.md#fiddler-everywhere-mcp-and-public-skills).

+## VS Code
+
+`rea setup --client vscode` configures the default VS Code user profile's
+`mcp.json`. Setup honors `VSCODE_PORTABLE` and `VSCODE_APPDATA` when they are
+present in its environment. It cannot infer a running window's named profile
+or `--user-data-dir`; configure that profile separately when needed.
+
+`rea setup --client copilot_cli` instead configures Copilot's user
+`mcp-config.json`. VS Code can forward eligible profile servers to Copilot
+sessions; see the [VS Code MCP configuration reference](https://code.visualstudio.com/docs/agents/reference/mcp-configuration).
+
 ## GitHub Copilot CLI

 Setup preserves an existing `tools` selection in the REA registration, including
@@ -170,14 +220,25 @@ and Claude Code reports that autocompact is thrashing. To avoid this:
  `mcpServers.rea` entry in `~/.claude.json` (`$CLAUDE_CONFIG_DIR/.claude.json`
  when that variable is set), then restart Claude Code. Setup keeps this
  override.
+- To remove entire tool families from the upfront catalog, run
+  `rea setup --client claude_code --tool-families <ids>` with the families the
+  workflow needs (see [the advertising scope contract](mcp-contracts.md#tool-family-advertising-scope)).
+  Out-of-scope tools are not advertised and their calls fail with the SDK's
+  disabled-tool error, so widen the selection when a task needs another
+  family. Setup writes the scope into the entry's `env` as
+  `REA_MCP_TOOL_FAMILIES`; rerun setup with a different selection to refresh
+  it, then restart Claude Code.

 The sizes above come from REA's own `tools/list`. A live Claude Code session
 against DeepSeek's API is unverified.

-For a client whose stdio reader rejects the complete catalog frame, add
-`"REA_MCP_OUTPUT_SCHEMA_PROFILE": "off"` to REA's `env` object and restart the
-client. This omits only advertised output schemas; REA still validates complete
-structured results against its canonical contracts. See [MCP output schema
+For a client whose stdio reader rejects the complete catalog frame, set
+`"REA_MCP_OUTPUT_SCHEMA_PROFILE": "compact"` to bound every advertised output
+schema, or `"off"` to omit them, in REA's `env` object, then restart the client.
+Both keep canonical result validation and complete structured results; `compact`
+keeps a widened root shape and `off` advertises nothing. On catalogs large
+enough that full input schemas alone approach the frame limit, also keep the
+input profile at its `compact` default. See [MCP output schema
 profiles](mcp-contracts.md#output-schemas).

 ## Kimi Code
@@ -210,6 +271,21 @@ registration but does not contribute to the derived tool timeout; raise
 `toolTimeoutMs` to cover a longer selected JADX deadline.
 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`, `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
+supported prlimit overrides, Darwin Swift compiler/SDK/module-cache selections,
+and compile timeout, logging level and explicitly configured reference-secret
+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. 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.
@@ -267,6 +343,15 @@ Setup and doctor follow Qwen Code's tilde and working-directory-relative home
 overrides. Qwen Code also discovers personal skills in `~/.agents/skills`,
 where setup installs the bundled workflow.

+If an existing direct-script registration fails with `env: node: No such file or
+directory`, refresh it through setup as described under [Launchers and PATH](#launchers-and-path).
+For an immediate Qwen-specific workaround, when Node is installed in
+`/opt/homebrew/bin`, add `"PATH": "/opt/homebrew/bin:${PATH}"` to that server's
+existing `env` object and restart Qwen. Qwen expands `${PATH}` from its parent
+environment; other clients can use different substitution syntax. Qwen's stdio
+launcher inherits the parent `PATH` and applies server overrides; a reduced
+parent environment does not establish that Qwen removed Homebrew from it.
+
 ## Antigravity

 Antigravity 2.0 discovers personal skills in `~/.gemini/config/skills`.
@@ -418,17 +503,51 @@ comments and unrelated settings. It resolves that file from `HERMES_HOME`, else
 from the platform default Hermes itself uses — `%LOCALAPPDATA%\hermes` on
 Windows, `~/.hermes` elsewhere — including any `HERMES_DATA_DIR_SUFFIX`. Hermes
 connects an entry unless `enabled` is false, so setup states `enabled: true`.
+Aliases whose anchor is defined in the `rea` entry retain their original resolved
+values when setup refreshes or uninstall removes that entry. Setup does not
+redirect another server's alias to REA's new launcher or policy.
+This also covers an anchor on the removed registration key. References to
+definitions outside the entry keep sharing the original value, including when
+another definition later reuses the same anchor name.

 Hermes personal skills install under the active Hermes home's `skills` directory.
-Setup, doctor and uninstall follow the root's `active_profile` selection, as
-plain Hermes CLI commands do. An explicit `HERMES_HOME` pointing to
-`profiles/<name>` selects that named profile directly. An invalid, missing or
-deleted sticky profile is reported instead of writing into the default home;
-it also remains an unresolved skill selection, so setup cannot report a
-successful empty installation. Overrides nested beneath the native Hermes home
-use that native home's sticky selection and profile root together, matching
-[Hermes's root rules](https://github.com/NousResearch/hermes-agent/blob/748c79a1c6873124d84071cdabb4062a75913e1f/hermes_constants.py#L83).
-Repair the profile or run `hermes profile use default` before retrying.
+Setup, doctor and uninstall share REA's sticky-profile resolver.
+A custom `HERMES_HOME` outside the platform default home
+reads its own `active_profile`. An override physically inside the default home
+uses that default home's sticky selection and profile root together, including
+when the final override directory does not yet exist.
+
+For example, with `HERMES_HOME=~/.hermes/sub` and `~/.hermes/active_profile` set
+to `coder`, setup selects `~/.hermes/profiles/coder/config.yaml` and that
+profile's skills directory. It does not read `~/.hermes/sub/active_profile`.
+Without an outer named selection, this override uses `~/.hermes/sub/config.yaml`.
+Use a home outside the platform default tree for an independent sticky selection.
+
+This describes REA's current routing, not full Hermes CLI equivalence.
+At Hermes commit `748c79a1`, the
+[sticky lookup](https://github.com/NousResearch/hermes-agent/blob/748c79a1c6873124d84071cdabb4062a75913e1f/hermes_cli/main.py#L612-L632)
+also reads the outer selection, but
+[`resolve_profile_env`](https://github.com/NousResearch/hermes-agent/blob/748c79a1c6873124d84071cdabb4062a75913e1f/hermes_cli/profiles.py#L2431-L2461)
+resolves it beneath the configured `HERMES_HOME`. For nested overrides, confirm
+the profile Hermes actually uses and point `HERMES_HOME` directly at that
+`profiles/<name>` directory before setup. Compatibility is tracked in
+[#3939](https://github.com/morluto/rea/issues/3939).
+
+REA resolves existing ancestor directories before checking physical containment,
+including symlinks and junctions, even when the override directory does not exist.
+An override beneath a symlinked default home therefore uses the default home's
+sticky selection. If `~/.hermes/link` points outside the default home,
+`HERMES_HOME=~/.hermes/link/new` instead uses that override root, whether or not
+`new` exists. Previewed destinations retain the configured path spelling.
+An unreadable path or dangling alias leaves the home unresolved; repair that path
+before configuring Hermes. Inspect setup's previewed destinations before applying
+changes.
+
+An explicit `HERMES_HOME` pointing to `profiles/<name>` selects that named
+profile directly, bypassing sticky selection. An invalid, missing or deleted
+sticky profile is reported instead of writing into the default home; repair the
+profile or run `hermes profile use default` before retrying. It also remains an
+unresolved skill selection, so setup cannot report a successful empty installation.
 REA follows `HERMES_HOME` whitespace trimming, environment-variable expansion,
 and home expansion before resolving that profile. Setup previews the resolved
 configuration and skill destinations; doctor and uninstall use those same paths.
@@ -445,10 +564,12 @@ installs its skill copy there.
 ## Factory Droid

 For [Factory Droid](https://docs.factory.com/harness/mcp), setup writes
-`mcpServers.rea` into the user-level `~/.factory/mcp.json`. Entries carry
-`command`, `args`, and `env`. Droid discovers personal skills from
-`~/.factory/skills` ([skills](https://docs.factory.com/harness/skills)), so
-setup installs its skill copy there.
+`mcpServers.rea` into the user-level `~/.factory/mcp.json` (the
+`FACTORY_HOME_OVERRIDE` override replaces the home that contains `.factory`).
+Entries carry `command`, `args`, and `env`. Droid discovers personal skills
+from `~/.factory/skills` ([skills](https://docs.factory.com/harness/skills),
+following `FACTORY_HOME_OVERRIDE` when set), so setup installs its skill copy
+there.

 ## Trae

@@ -496,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
@@ -521,10 +643,16 @@ boundaries. FreeBuff MCP loading and skill discovery have not been verified
 with an installed native FreeBuff client/version; filesystem tests cover REA's
 editing, discovery, and ownership behavior only. Automatic applicability
 requires the FreeBuff profile directory even when the shared MCP file exists.
+When uninstall cannot establish FreeBuff or another shared-storage reader from
+product discovery, a malformed or unreadable shared MCP file is retained
+unchanged and does not stop other REA removals, including `--purge-data`. When
+FreeBuff or ZCode product applicability is established or unresolved, the same
+malformed shared file stops uninstall before removals. See
+[Diagnose, update, and remove](installation.md#diagnose-update-and-remove).

-FreeBuff is main-only and is not in a published release yet; npm 6.7.0 is the
-latest. `rea setup --client freebuff` against `@latest` reports an unsupported
-client until a release containing it is published.
+FreeBuff setup support requires `rea-agents@6.8.0` or later. Older versions
+reject `rea setup --client freebuff` as an unsupported client. See the
+[installation guide](installation.md#supported-agents) for client availability.

 ## DeepSeek Harness

@@ -591,8 +719,10 @@ become active again. Malformed applicable files block setup before changes.
 Grok Build loads `[mcp_servers.rea]` from `$GROK_HOME/config.toml`, or from
 `~/.grok/config.toml` when `GROK_HOME` is unset or empty. Setup edits that server
 table, `[mcp_servers.rea.env]`, and a root `disabled_mcp_servers` entry that
-names `rea`. It sets `startup_timeout_sec = 30` and leaves every other name
-in that list. The shared skill installed under `~/.agents/skills` is already
+names `rea`. It defaults `startup_timeout_sec` to 30 seconds, preserves an
+existing positive timeout, and leaves every other name in that list.
+[Grok supports longer startup timeouts](https://docs.x.ai/build/features/mcp-servers)
+for cold package-runner launches. The shared skill installed under `~/.agents/skills` is already
 on Grok Build's skill path.

 Grok Bot (`grok_bot`) is detected from `~/.grokbot`, or from `SAND_DATA_ROOT`
@@ -622,10 +752,6 @@ can override an inherited disable. Lower files and other server entries remain
 unchanged; a legacy server named `servers` that conflicts with the native table
 requires manual repair before setup can write.

-When Hermes aliases refer to an anchored REA entry, refreshing or removing REA
-retains the aliases' original resolved values. Setup does not redirect another
-server's alias to REA's new launcher or policy.
-
 With no client selected, the interactive skill choice targets the shared
 `~/.agents/skills` copy. Selecting a client targets its personal destination
 when supported. Use `rea setup --skill-client shared --skill` for the shared
@@ -11,6 +11,16 @@ and provider lanes. Each record below states its host, client version, model
 fixture, and remaining coverage; a native-client run with a loopback model does
 not establish live model-service acceptance.

+## Launch environment verification
+
+`rea mcp doctor --json` starts the production MCP adapter with the current runtime
+executable and environment. A healthy result establishes that adapter's
+initialization, discovery and target-free request flow; it does not verify a
+client's configured launcher or its inherited environment. Test the generated
+registration through the actual client, including a reduced `PATH` when checking
+desktop or service startup. Record the client version and launch environment
+separately from terminal doctor results. See [launcher troubleshooting](client-configuration.md#launchers-and-path).
+
 ## Published Pi code-mode renderer limit

 A separate probe of the published `@earendil-works/pi-codemode` 1.1.0 and 1.2.0
@@ -53,6 +63,14 @@ skill setting; Hermes discovers it through the selected `HERMES_HOME`.
 Set `REA_VERIFY_HERMES_STICKY_PROFILE=1` to exercise native Hermes selection of
 a named sticky profile with `HERMES_HOME` still pointing to its root.

+For Qwen on POSIX, set `REA_VERIFY_QWEN_REDUCED_PATH=1` and select its JavaScript
+entry point with `REA_VERIFY_QWEN_COMMAND` to test a restricted client environment.
+Setup retains the caller's `PATH`; the native Qwen `chat` or `call` run then uses
+an isolated `PATH` containing only Bash for the shell-tool fixture. The lane
+checks that `node`, `npm` and `npx` cannot be found and uses the generated REA
+registration unchanged. Its receipt records `reducedPath`, `clientPath` and
+`registrationCommand`; the option alone does not establish a passing native run.
+
 The Qwen lane also supports native Windows (verified with Qwen Code 0.25.1 and
 Node 24.19.0 for both `chat` and `call`). With Node 24.18.0, the same `call`
 journey reached full Evidence readback but the client aborted during exit with
@@ -169,6 +169,7 @@ cannot partially apply. Clients coordinating writes can supply
 | `capture.decoder_old_generation_mib`                          | Next owned capture decoder                                             |
 | `javascript.analysis_timeout_ms`, `javascript.max_heap_mb`    | Next source analysis / new JavaScript worker                           |
 | `wasm.command_timeout_ms`                                     | Next WABT operation                                                    |
+| `native.matching_representation_bytes`                        | Next `match_native_functions` request                                  |

 ### Precedence and lifetime

@@ -243,6 +244,8 @@ Inspection then reports the runtime value while retaining the launch error.
 Reset exposes the invalid launch state again; it does not repair or replace it
 with the built-in default. Provider availability and execution must resolve the
 same effective setting so readiness changes along with repair and reset.
+`REA_NATIVE_MATCHING_REPRESENTATION_BYTES` is validated the same way, by
+`match_native_functions` alone.

 ## Keep a fixed ceiling honest

@@ -375,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.
@@ -53,7 +53,7 @@ Every collection supports `fields`, `offset` and `limit`; its stable row ID is
 always included. Selection changes delivery, not source inspection. Pages keep
 source coverage and parent Evidence links. Page exhaustion does not establish
 absence in a partial source. Complete Evidence remains accessible through
-`get_evidence` and Evidence bundle export.
+`get_evidence_bundle` and Evidence bundle export.

 The summary's `probe_issues` counts files with reported issues and their retained
 issue entries. It previews at most two such files, including stable `file_id`,
@@ -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
@@ -691,12 +691,8 @@
              "type": "object",
              "properties": {
                "logical_path": { "type": "string" },
-                "declared_sha256": {
-                  "anyOf": [{ "type": "string" }, { "type": "null" }]
-                },
-                "calculated_sha256": {
-                  "anyOf": [{ "type": "string" }, { "type": "null" }]
-                },
+                "declared_sha256": { "type": ["string", "null"] },
+                "calculated_sha256": { "type": ["string", "null"] },
                "unpacked": { "type": "boolean" }
              },
              "required": [
@@ -705,7 +701,7 @@
                "calculated_sha256",
                "unpacked"
              ],
-              "additionalProperties": false
+              "additionalProperties": {}
            },
            {
              "type": "object",
@@ -731,7 +727,7 @@
                "calculated_md5",
                "unpacked"
              ],
-              "additionalProperties": false
+              "additionalProperties": {}
            }
          ]
        }
@@ -0,0 +1,316 @@
+# 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 of a chip whose bootloader is at offset 0, such as
+ESP32-C3 or ESP32-S3, is recognized as that bootloader image; the partition
+table, apps and data follow as undescribed bytes.
+
+## 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

@@ -275,7 +280,7 @@ Additional lanes are explicit, so the base lane stays small:
 REA_FIRMWARE_VERIFY_EXT4=1 npm run fixtures:firmware
 REA_FIRMWARE_VERIFY_EXT4=1 npm run verify:firmware

-# Existing Ghidra 12.1.x and its declared JDK required.
+# Existing Ghidra 12.x (>=12.1) and its declared JDK required.
 REA_FIRMWARE_VERIFY_GHIDRA=1 npm run verify:firmware
 ```

@@ -286,9 +291,48 @@ 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 extracted devicetrees

 Use [`inspect_devicetree`](devicetree.md) / `rea inspect-devicetree` on an
 extracted DTB for its node/property tree, reservations, hardware summary and
 selected phandle relationships. FDT v16/v17 inspection is portable and requires
 no external tool or disassembler.
+
+## Inspect Intel HEX and S-record images
+
+Use `inspect-artifact` / `inspect_artifact` on an Intel HEX or Motorola S-record
+file for its address regions, declared start address and record facts, then
+`extract-artifact` / `extract_artifact` for one raw file per region. Decoding is
+portable and requires no external tool. See
+[Intel HEX and S-record images](hex-records.md).
+
+## Inspect U-Boot legacy uImages
+
+`inspect-artifact` / `extract-artifact` recognize a legacy uImage by its
+`0x27051956` magic and inventory it without running or decompressing it.
+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 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 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

@@ -3,7 +3,7 @@
 REA can analyze DOS MZ executables and explicitly selected COM images through the bring-your-own Ghidra adapter.
 The Linux x64 and macOS arm64 verification lanes exercise actual 16-bit disassembly and
 decompilation through the CLI and stdio MCP. Provider admission accepts Ghidra
-12.1.x and that installation's declared JDK range. The verification lane uses
+12.x (>=12.1) and that installation's declared JDK range. The verification lane uses
 Ghidra 12.1.4 and JDK 21; no DOS emulator or cross-compiler is required.

 ## Open and inspect
@@ -30,6 +30,17 @@ signal. Confirm resource causes from process output or host/container records;
 operation-scoped JVM `OutOfMemoryError` observations retain their separate resource
 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
+`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
+omitting cumulative launcher stdout/stderr and launch-support output. Startup,
+process, protocol and other remote failures retain full session diagnostics.
+The Ghidra client still owns its bounded cumulative output; this projection does
+not clear it or alter session readiness. Log paths refer to the owned ephemeral
+runtime and are removed by normal cleanup.
+
 Provider selection and profile identity follow
 [MCP contracts](mcp-contracts.md#identity-and-discovery). One deep
 provider stays bound to the target; runtime failure never selects another
@@ -160,6 +171,43 @@ have no file backing. ELF mappings are observed
 without independent format-specific load-image verification, as the result's
 status and limitations state.

+For large relocation inventories, select MCP `inspect_native_load_image` with
+`detail: "summary"`. It returns verification state, observed identity and counts,
+while retaining complete Evidence. Use `normalized_result.parent_evidence_id`
+with `inspect_analysis_view` and a view such as:
+
+```json
+{
+  "kind": "native-load-image",
+  "collection": "relocations",
+  "offset": 0,
+  "limit": 32,
+  "fields": ["address", "status", "type"]
+}
+```
+
+Collections are `source_files`, `mappings`, `relocations`, `entry_points`,
+`entry_context`, `checks` and DOL `sections`. Optional
+`indices` select original row indices before paging; empty indices select none.
+Fields are collection-specific. Relocation defaults omit byte payloads; check defaults omit potentially large `expected`/`observed` inventories. Request those fields explicitly when needed. Other collections default to all fields. Metadata recovery remains counted and retained in complete parent Evidence.
+Parent Evidence, collection and `source_index` identify a row, including same-address
+relocation alternatives. Null counts or rows mean unrecorded or inapplicable;
+they never establish an empty observation. Exhausting a page does not upgrade
+unsupported verification or runtime coverage. Pages query immutable retained
+facts without reopening the target or repeating Ghidra work.
+Each page carries the source's structured `verification_status` independently
+of its page coverage.
+
+CLI summary delivery requires a complete Evidence bundle:
+
+```sh
+rea inspect-native-load-image <path> --provider ghidra --detail summary --evidence_output /new/load-image.json --json
+```
+
+Read selected pages later through `inspect-analysis-view` using the returned
+parent ID and an `evidence-file` source pointing to that bundle. Complete
+delivery remains the default in both adapters.
+
 An unsuccessful numeric procedure lookup reports the current Ghidra image base
 and gives the CLI commands above alongside the corresponding MCP operations.
 Repeat any target-format, architecture, and entry-point options used to open the
@@ -251,7 +299,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
@@ -1,9 +1,18 @@
 # Godot PCK archives

-`inspect-artifact` and `extract-artifact` read ordinary Godot PCK formats 2, 3
+`inspect-artifact` and `extract-artifact` read ordinary Godot PCK formats 1, 2, 3
 and 4 without running the game or requiring Godot. Official Godot 4.4.1, 4.6.1
-and 4.7.1 produced these respective formats in verification; other engine
-releases have not been verified. Format 1 is unsupported.
+and 4.7.1 produced formats 2, 3 and 4 respectively in verification; other engine
+releases have not been verified. Format 1 compatibility follows the
+[Godot 3.5 loader](https://github.com/godotengine/godot/blob/3.5/core/io/file_access_pack.cpp#L201-L242)
+and [exporter](https://github.com/godotengine/godot/blob/3.5/editor/editor_export.cpp#L1094-L1164)
+layout and is covered by synthetic standalone and embedded fixtures; an actual
+Godot 3 export has not been exercised.
+
+Format 1 uses an 84-byte header, no pack or member flags, and absolute member
+offsets in the complete source file, including an embedded executable carrier.
+Its reported flags and file base are zero because those fields are absent.
+Zero-offset removal records remain unsupported; REA does not apply patches.

 Inspection retains the original header and directory facts, including engine
 version, flags, declared file count, source paths, offsets and declared MD5.
@@ -36,7 +36,7 @@ The MCP tool `project_harmony_application_graph` takes the same

 - exact component paths, artifact IDs, and hashes (manifests, Ark bytecode,
  resources, native libraries, JavaScript, signing)
- a packaging-model hint: Stage is claimed only from a `module.json` entry
+- a packaging-model hint: Stage is claimed only from an exactly cased `module.json` entry
  outside a classified resource path, FA only from `config.json` outside a
  classified resource path, otherwise `unknown`
 - FA resources under `assets/<module>/resources/` as well as Stage `resources/`
@@ -46,6 +46,9 @@ The MCP tool `project_harmony_application_graph` takes the same
 - path-based N-API bridge hypotheses between bytecode and `libs/<abi>` native
  libraries

+An unavailable manifest can still supply a path-based model hint; its content
+identity remains unknown. Manifest names follow case-sensitive ZIP member names.
+
 File and slice occurrences supply component and child-package paths; directory
 trees and symlinks retain their identities in the source inventory without
 being classified as code files. Ark and JavaScript runtime hints summarize the
@@ -0,0 +1,129 @@
+# Intel HEX and S-record images
+
+REA inventories Intel HEX (I8HEX, I16HEX, I32HEX) and Motorola S-record (S19,
+S28, S37) programming files through `inspect-artifact` / `inspect_artifact`, and
+materializes their decoded bytes through `extract-artifact` /
+`extract_artifact`. Decoding is static and needs no external tool.
+
+```sh
+rea inspect-artifact ./firmware.hex --json
+rea inspect-artifact ./firmware.s37 --detail summary --evidence_output evidence.json --json
+rea extract-artifact ./firmware.hex --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 recognized only when its first line, starting at byte 0, is a fully
+valid record: correct start character, hex digits, byte count, checksum, known
+record type and fixed length. The file name does not matter. A byte-order mark,
+a leading blank line or an invalid first record leaves the file unrecognized,
+so it falls through to plain `file` classification. Recognition never searches
+for a record later in the file. The container formats are `intel-hex` and
+`srec`.
+
+## Regions and metadata
+
+Each inventory entry is one address-contiguous region of decoded bytes, named
+`0x<start>-0x<end>.bin` with an inclusive end address of eight lowercase hex
+digits, for example `0x08000000-0x0800001f.bin`. Regions are listed in ascending
+address order. Out-of-order records are sorted into regions; gaps separate
+regions and are never filled.
+
+Region `format_metadata` (`hex-record-region`) records `start_address`,
+`end_address`, `length`, `record_count`, and `first_line`/`last_line`: the
+1-based line span of the contributing data records.
+
+Root `format_metadata` (`hex-records`) records:
+
+| Field                                             | Meaning                                                                           |
+| ------------------------------------------------- | --------------------------------------------------------------------------------- |
+| `encoding`, `variant`                             | `intel-hex` or `srec`; the variant derived from the record types seen, or `mixed` |
+| `line_count`, `record_count`, `data_record_count` | Lines read, non-blank records, and data records                                   |
+| `data_bytes`, `duplicate_bytes`, `region_count`   | Unique decoded bytes, bytes rewritten with identical values, and regions          |
+| `lowest_address`, `highest_address`               | Address bounds of the decoded bytes, or `null` without data                       |
+| `termination`                                     | Whether Intel `01` or S-record `S7`/`S8`/`S9` was present                         |
+| `start_address`, `start_address_record`           | The Intel `05` EIP or the `S7`/`S8`/`S9` address, with its record type            |
+| `start_segment_cs`, `start_segment_ip`            | The Intel `03` CS:IP pair                                                         |
+| `header_hex`, `header_text`                       | S-record `S0` data as hex, and as text only when every byte is printable ASCII    |
+| `declared_data_record_count`                      | The last `S5`/`S6` count, validated against the data records before it            |
+
+`variant` is `null` for an S-record file in which no data or termination
+record establishes an address width. Start addresses are declared facts, not
+proven entry points.
+
+## Facts, limitations and failures
+
+| Situation                                                                                  | Outcome                                                                      |
+| ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
+| Gaps between regions                                                                       | Separate regions; never zero-filled                                          |
+| Out-of-order records                                                                       | Sorted into regions                                                          |
+| An address written twice with the same value                                               | Accepted and counted in `duplicate_bytes`                                    |
+| An address written twice with different values                                             | Fails, naming the address and the line spans of both writes                  |
+| Checksum mismatch, odd hex length, non-hex character, byte count disagreeing with the line | Fails with the line, declared and computed values, and record type           |
+| Line longer than 521 (Intel) or 514 (S-record) characters, excluding the line ending       | Fails before the line is decoded                                             |
+| Intel type `06` or higher, `S4`, wrong fixed length for Intel `01`–`05` or `S5`–`S9`       | Fails                                                                        |
+| Missing Intel `01` or `S7`–`S9`                                                            | Regions are returned; coverage is unknown and the file may be truncated      |
+| A non-blank record after termination, or a second `S0`                                     | Fails; blank lines are allowed anywhere                                      |
+| `S5`/`S6` count different from the data records before it                                  | Fails                                                                        |
+| Termination type not matching the data address width                                       | Reported as a limitation; the declared fact is kept                          |
+| Conflicting repeated `03`/`05` start records                                               | Fails; identical repeats are allowed                                         |
+| An Intel data record whose 16-bit offset wraps past `0xFFFF`                               | Fails: producers disagree on whether the address wraps or continues linearly |
+| I16HEX data above `0xFFFFF`, or data crossing the S1/S2/S3 address width                   | Fails                                                                        |
+
+Lowercase hex, LF and CRLF line endings, and trailing spaces or tabs are
+accepted. A CR not followed by LF is an invalid character. Failures apply to
+the whole file and return no partial regions.
+
+## Limits
+
+The file must be at most 128 MiB. Every data byte needs two hex digits, so the
+decoder reserves at most half the file size for decoded bytes before reading,
+and stores only written addresses. The decoder retains at most 65,536
+address-discontiguous record runs before merging them into regions. A run is a
+sequence of consecutive records whose addresses continue each other. Both 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). The line-length limits are
+the one-byte record count: Intel HEX allows 255 data bytes, while S-record
+counts include address and checksum bytes.
+
+Decoded regions are cached only for the reader's lifetime. Each open checks
+its admitted carrier identity again. Region streams copy at most 64 KiB per
+chunk, so consumers cannot mutate cached bytes and opening a large region does
+not copy it in full. Caller cancellation keeps its exact reason, and closing
+the reader waits for active region streams to close.
+
+## Analyzing a region
+
+Inventory does not establish the CPU, byte order or memory map, or that a
+declared start address is executable. 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. A caller-selected
+Ghidra language and base address for raw-binary imports is tracked in
+[#4246](https://github.com/morluto/rea/issues/4246); Thumb-only Cortex-M images
+may be refused or decoded in ARM state until
+[#5744](https://github.com/morluto/rea/issues/5744) is resolved.
+
+## Verification
+
+Fixtures with computed checksums cover supported record types, checksums,
+termination, address gaps and overlaps, resource refusals, inventory, extraction
+and reader lifecycle. CLI and stdio MCP tests exercise the same artifact
+provider and advertised schemas, including retained Evidence views.
+
+GNU objcopy 2.40 output was also checked on Linux: the system `true` ELF was
+converted to Intel HEX and S-record, with additional address-rebased I32HEX
+and S37 cases. Each yielded 13 regions. A 19,124,817-byte Intel HEX conversion
+of the system Python 3.11 ELF yielded 11 regions containing 6,799,261 decoded
+bytes. Public CLI inspection and extraction matched GNU BFD address ranges
+and independently exported section bytes. Adjacent GNU sections were joined
+without filling address gaps. These are real producer outputs from system
+applications, not vendor-firmware or target-execution verification; srec_cat
+and other producers remain unverified. No general speedup is claimed.
@@ -40,7 +40,12 @@ Record the image digest, REA source revision and these dependency versions:
 - OpenSSL and cURL advertising HTTP3 and HTTP2 in `curl --version`.

 The verified guest used Python 3.14.7, cURL 8.22.0, ngtcp2 1.25.0 and nghttp3
-1.18.0. Other dependency profiles need verification. Back up the guest's
+1.18.0. The current requirements update certifi from 2026.7.22 to 2026.10.19
+to remove the compromised emSign trust root described in
+[GHSA-6q48-6c7w-9gw2](https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2).
+The revised dependency graph has not been rerun in that sealed guest; the
+historical verification does not cover this update. Other dependency profiles
+need verification. Back up the guest's
 `/etc/hosts` before adding `127.0.0.1 lab.test`. Reserve guest TCP/UDP loopback
 ports 18443 and 19443. These changes belong only to the disposable guest.

@@ -80,6 +80,71 @@ Native MCP 1.1.2 can navigate in the previously focused pseudocode tab when swit

 Native tool observations retain actual tool names and complete JSON text. Upstream `structuredContent` can be a shortened preview even while text contains the full result. REA reads the full native representation and rejects missing/malformed text instead of treating previews as complete observations.

+### Migrate a legacy attached registration
+
+Both attached profiles remain supported. Migrating replaces the upstream server;
+adding `"protocol": "native"` to a legacy Python proxy registration is insufficient.
+The native plugin is separate from mrexodia/ida-pro-mcp, and upgrading mrexodia to
+its modern tool catalog does not select this profile.
+
+1. Back up the working registration file. Install and start the native plugin
+   using its [upstream instructions](https://github.com/0xshlomil/ida-free-mcp).
+   IDA and the plugin are bring-your-own; REA does not install or build them.
+   Use a build with the navigation correction described above, and restrict its
+   listener to loopback or apply the documented host firewall restriction.
+   Stop the legacy endpoint first if both servers would use the same port.
+2. Open the same original input binary in IDA and wait for analysis. Keep that
+   file readable by REA. The native metadata resource must report its recorded
+   input SHA-256; the resource's `path` identifies the database, not an input
+   file to substitute. Universal Mach-O inputs still require a thin extraction.
+3. Replace the registration, using the native plugin's actual local endpoint.
+   For example, this legacy registration:
+
+   ```json
+   {
+     "mode": "attached",
+     "command": "python",
+     "args": [
+       "/absolute/path/to/ida_pro_mcp/server.py",
+       "--ida-rpc",
+       "http://127.0.0.1:13337"
+     ]
+   }
+   ```
+
+   becomes:
+
+   ```json
+   {
+     "mode": "attached",
+     "protocol": "native",
+     "url": "http://127.0.0.1:13337/mcp"
+   }
+   ```
+
+   Keep `REA_IDA_MCP_CONFIG` pointing at the replacement file and close/reopen
+   the REA binary session to connect with it. If changing the environment's
+   configuration path, restart the MCP server as described above. Do not reuse
+   the legacy RPC URL as an MCP HTTP endpoint.
+
+4. Check `binary_session` availability before resuming workflows. Direct
+   `procedure_callers` becomes unavailable and dossier callers remain unknown;
+   incoming address xrefs do not establish direct call edges. Native strings
+   use C-string rendering. Assembly and instruction reads no longer navigate
+   the GUI; native pseudocode still changes focus and closes existing
+   pseudocode tabs. IDA Free decompilation may require cloud access and consent.
+5. Run the [real-provider verification](#verification) with two distinct
+   functions and the required second-function marker. Supply independently
+   known string and xref oracles for those checks. Existing Windows evidence
+   covers IDA Pro 9.3 with the documented source build and listener change;
+   it does not establish stock-plugin, Windows Free, or native macOS behavior.
+   A valid registration or successful doctor check alone does not verify the
+   connection, target identity, or function switching.
+
+REA continues to verify identity and image base around requests and closes only
+its connection, preserving the attached database. Restore the backed-up legacy
+registration and its upstream endpoint to return to the legacy profile.
+
 The legacy producer moves the active GUI as a side effect: assembly and raw function instructions jump to the function, and successful pseudocode opens or reuses a pseudocode view. A function dossier does both. Native GUI decompilation also changes the active view. `binary_session` reports these operations with `effects.may_show_ui: true`; headless operations and the other attached operations report `false`.

 ## Give REA a target for headless analysis
@@ -175,7 +240,7 @@ The verifier requires the resolved procedure in both inventory and procedure sea

 The initial real workflows use stdio registrations for the legacy Windows GUI profile and a Windows x64 headless supervisor with IDA 9.3. The headless workflow has also passed on macOS arm64 with IDA Professional 9.1 (build 9.1.250226) against the same upstream commit `c133c3853faa111a9b00ee615c013b720d0c4acd`, using a source-built arm64 Mach-O fixture; Mach-O C symbols carry a leading underscore, so the procedure name is `_rea_fixture_add`. Streamable HTTP is tested against a loopback MCP fixture with the pinned client SDK; a real IDA HTTP-supervisor workflow remains unverified. Linux headless engine operation, other IDA releases, architectures, and modern attached GUI tools require their corresponding real workflows before support is claimed.

-Native Windows verification uses IDA Pro 9.3 with the public two-function fixture and Windows `whoami.exe`, using upstream `c9d15d98e8a143fc74f6e14037c48f63889b6d6c` with a loopback-listener change. It covers production CLI/MCP parity, distinct-function switching, identity and connection cleanup. See the [correctness and performance measurements](https://github.com/morluto/rea/blob/main/experiments/analysis-efficiency/ida-native-windows.md). This follow-up did not run Windows IDA Free or native macOS.
+Native Windows verification uses IDA Pro 9.3 with the public two-function fixture and Windows `whoami.exe`, using upstream `c9d15d98e8a143fc74f6e14037c48f63889b6d6c` with a loopback-listener change. It covers production CLI/MCP parity, distinct-function switching, identity and connection cleanup. See the [correctness and performance measurements](https://github.com/morluto/rea/blob/a2e2c29b59e8775b0e6aedb09a9eb16adf32646b/experiments/analysis-efficiency/ida-native-windows.md). This follow-up did not run Windows IDA Free or native macOS.

 Headless readiness distinguishes an explicit `auto_analysis_ready: false` from
 unknown readiness (`null`). The former returns a retryable capability refusal
@@ -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), [.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), [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),
@@ -3,13 +3,14 @@
 Run REA, connect your selected agents, and check the tools needed for your task.
 Setup previews configuration changes and asks for approval before applying them.

-| Task                              | Section                                                                                             |
-| --------------------------------- | --------------------------------------------------------------------------------------------------- |
-| Connect an agent                  | [Start setup](#start-setup), then [review changes](#review-setup-changes)                           |
-| Diagnose one task                 | [Scoped readiness checks](#check-readiness-for-your-task)                                           |
-| Configure an analysis engine      | [Hopper](#hopper), [Ghidra](#ghidra), the [IDA guide](ida-provider.md), or [Kuna](kuna-provider.md) |
-| Update or remove REA              | [Maintenance](#diagnose-update-and-remove)                                                          |
-| Resolve a client-specific problem | [Client configuration](client-configuration.md)                                                     |
+| Task                               | Section                                                                                             |
+| ---------------------------------- | --------------------------------------------------------------------------------------------------- |
+| Connect an agent                   | [Start setup](#start-setup), then [review changes](#review-setup-changes)                           |
+| Install a Claude Code/Codex plugin | [Agent plugins and marketplaces](#agent-plugins-and-marketplaces)                                   |
+| Diagnose one task                  | [Scoped readiness checks](#check-readiness-for-your-task)                                           |
+| Configure an analysis engine       | [Hopper](#hopper), [Ghidra](#ghidra), the [IDA guide](ida-provider.md), or [Kuna](kuna-provider.md) |
+| Update or remove REA               | [Maintenance](#diagnose-update-and-remove)                                                          |
+| Resolve a client-specific problem  | [Client configuration](client-configuration.md)                                                     |

 ## Start setup

@@ -84,9 +85,16 @@ For an existing configuration, setup and uninstall recovery refuse a detected
 replacement or edit and name the recovery backup. Quit clients before editing their configuration;
 these checks do not lock out another writer modifying the same file in place,
 or exclude pathname changes between the final check and publication.
+Setup refreshes an existing `rea` registration only when its launcher proves REA
+ownership. Foreign or unresolved launcher identity blocks setup before any
+backup or write, including an OpenCode legacy entry that migration would remove.
+Review the existing launcher and manually rename or remove that registration to
+approve replacing it. A different existing installation path is foreign to the
+current entrypoint; a path that cannot be resolved remains unknown. Cordis uses
+its stable REA entry ID instead of launcher identity.
 Setup also retains valid environment overrides in REA's existing server entry,
 such as `REA_MCP_INPUT_SCHEMA_PROFILE`, `REA_MCP_OUTPUT_SCHEMA_PROFILE`, and
-`REA_MCP_MAX_RESPONSE_BYTES`.
+`REA_MCP_MAX_RESPONSE_BYTES`, and `REA_MCP_TOOL_FAMILIES`.
 Detected provider settings replace only matching environment keys.
 Setup manages REA's launcher, selected provider settings, and recommended timeout
 defaults. Codex approval policies, tool selections, and other caller-owned server
@@ -162,7 +170,9 @@ Setup leaves existing skill copies in other locations untouched.
 Setup refuses symbolic links at the selected skill directory or its managed
 `references` directory, matching uninstall and update's ownership rules. Use a
 regular skill directory, or select `--skill=false` to configure the client
-registration without installing the bundled skill.
+registration without installing the bundled skill. A non-directory ancestor is
+reported as `ENOTDIR`; preserve the blocking file and correct the directory path
+before rerunning setup.
 The final selected directories are checked before approval and again before
 setup changes any client or Hopper installation. Unselected client destinations
 do not block other setup choices. Doctor reports linked or non-directory skill
@@ -204,7 +214,8 @@ identity remains available at `identity.catalog`.

 Setup pins package-runner MCP registrations to the exact installed REA version,
 installs the matching skill and on-demand references in the same plan, and adds
-`startup_timeout_sec = 30` for Codex and Grok Build. Codex also receives a
+`startup_timeout_sec = 30` for Codex and Grok Build when no positive timeout
+is already configured. Codex also receives a
 `tool_timeout_sec` derived from known provider startup plus operation headroom.

 ## Limit REA to one project or agent profile
@@ -264,7 +275,7 @@ After reviewing an update plan, rerun that same prefixed setup command without
 `--dry-run` and approve its exact changes. Profile removal likewise needs the
 prefix on `claude mcp remove --scope user rea` and any `rea uninstall` command;
 keep the broader client scope of uninstall in mind. Restart the selected
-profile after changing its pinned registration.
+profile after changing its registration.

 `claude mcp remove` removes only the registration. To remove REA from this
 profile without running the broader uninstall flow, first back up the profile's
@@ -314,34 +325,30 @@ commands. Record an existing selection first if you intend to restore it after
 finishing. The configuration path below is the default profile's
 `~/.claude.json`; a different active profile uses its own config root instead.

-Register with the variable unset:
-
-<!-- x-release-please-start-version -->
+Register with the variable unset, substituting the absolute runtime and entry
+script from your existing installation or setup dry-run:

 ```bash
-claude mcp add --scope local rea -- npx -y rea-agents@6.8.0 mcp
+claude mcp add --scope local rea -- "/absolute/path/to/node" "/absolute/path/to/rea/scripts/rea.mjs" mcp
 ```

-On native Windows, use the same project directory and wrap the package-runner
-shim so the stdio client can launch it:
+On native Windows, use the same project directory and absolute paths:

 ```powershell
-claude mcp add --scope local rea -- cmd.exe /d /c npx -y rea-agents@6.8.0 mcp
+claude mcp add --scope local rea -- "C:\Program Files\nodejs\node.exe" "C:\tools\rea\scripts\rea.mjs" mcp
 ```

-<!-- x-release-please-end -->
-
 Local scope stores the entry under that directory's path in `~/.claude.json`,
 so other projects don't load it. This route doesn't install the bundled skill.
 Avoid `--scope project`, which writes `.mcp.json` into the repository where it
 can be committed or copied. `rea doctor` and `rea uninstall` read only the
 user-level entry, so they don't report or remove a local-scope registration;
 remove it with `claude mcp remove --scope local rea` from the same directory.
-`rea update` doesn't refresh it either, so it stays on the version it names.
+`rea update` doesn't refresh it either, so it continues using the selected installation.
 To move it to a newer release, first back up the project entry in
 `~/.claude.json` and record its environment and other metadata. In particular,
 preserve caller-selected overrides such as `REA_MCP_INPUT_SCHEMA_PROFILE` and
-`REA_MCP_MAX_RESPONSE_BYTES`. Run `claude mcp remove --scope local rea` from the
+`REA_MCP_MAX_RESPONSE_BYTES`, and `REA_MCP_TOOL_FAMILIES`. Run `claude mcp remove --scope local rea` from the
 same directory, then recreate it with the platform-appropriate command above
 and the new version. Reapply every recorded environment value with Claude
 Code's `mcp add --env NAME=value` options and restore any other retained entry
@@ -374,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`                                              |

@@ -412,6 +419,13 @@ The public error code varies by caller: `capability_unavailable`,
 only a generic startup error. Check this prerequisite before following
 provider-specific recovery advice.

+`binary_session` still returns status on such a host. Providers whose
+readiness check reaches the owned-child launch, such as Ghidra's Java probe,
+JADX and Apktool, report themselves unavailable with a reason naming the
+missing `ps`. A provider that fails an earlier configuration check, such as
+JADX without `REA_JADX_MCP_JAR`, keeps that reason. The other providers keep
+their own status. `open_binary` keeps the refusal described above.
+
 ## Diagnose, update, and remove

 `rea doctor --json` is strictly read-only. `rea update` updates only the npm or Bun global installation that owns the running CLI. Source checkouts and package-runner copies must be updated through the mechanism that owns them; a fresh package-runner invocation can use `npx rea-agents@latest` or `bunx rea-agents@latest`. `rea uninstall` removes only REA-owned agent registrations and skill files; `--purge-data` additionally removes REA cache and state paths.
@@ -429,11 +443,19 @@ and other MCP servers. Purging removes REA's legacy cache and state under
 archives under `${XDG_CACHE_HOME:-~/.cache}/rea/hopper-releases`. Other cache
 namespaces remain intact. A caller-selected `REA_KUNA_CACHE_DIR` is retained
 and reported because REA cannot establish ownership of its entire contents.
+Lexically equivalent spellings of that default directory, including a trailing
+separator, a `.` segment, or a repeated separator, share its purge result.
+The comparison preserves POSIX `..` traversal and literal backslashes.
 A client configuration that is malformed, unreadable, or at an unsafe
-path stops the operation before anything is removed, and a client that fails
-while being updated stops the remaining removals. Uninstall reports each
-candidate `configuration_path` with its outcome. A client with multiple files
-keeps their individual `actions` alongside its aggregate status and detail,
+path stops the operation before anything is removed when that client's
+product applicability is established or unresolved. Shared registration
+storage such as `~/.agents/mcp.json` whose product cannot be established
+(for example when FreeBuff and ZCode discovery directories are absent) is
+retained unchanged and does not block other REA removals, including cache
+and state deletion with `--purge-data`. A client that fails while being
+updated stops the remaining removals. Uninstall reports each candidate
+`configuration_path` with its outcome. A client with multiple files keeps
+their individual `actions` alongside its aggregate status and detail,
 including earlier removals when a later file fails. The paths name
 the discovered configuration candidates, not resolved physical file identities.
 For JSON clients, uninstall removes every repeated `rea` member in the effective
@@ -495,6 +517,10 @@ Do not rename `index.cjs` to `index.mjs` or disable protection to make startup p

 ### Update the owning installation

+Read-only metadata and version checks time out after 10 seconds. This does not
+interrupt a package installation already in progress. If a probe cannot be
+stopped, the updater reports a cleanup failure.
+
 `rea update` installs the exact resolved
 release into the npm prefix or Bun global directory that owns the running
 package, then checks the new executable's version before reporting success.
@@ -525,8 +551,8 @@ non-TTY, and JSON modes without applying configuration changes.
 ## Released package and main

 Repository main documents its current code and generated catalog. `@latest`
-selects the npm release, and persistent MCP registrations are pinned to the
-version that performed setup. Installing newer instructions does not update a
+selects the npm release, and managed MCP registrations bind the installation
+that performed setup. Installing newer instructions does not update a
 running server or its registration.

 The npm release checked on **2026-10-11** was **6.4.0**, published from
@@ -649,6 +675,10 @@ an existing Hopper launcher is selected through `HOPPER_LAUNCHER_PATH`. Ghidra
 and IDA have their own provider-specific host requirements; Windows Ghidra uses
 the [experimental P0 boundary](windows-ghidra-p0.md).

+If the Linux package download receives an HTTP failure, setup includes the
+observed HTTP status in its `download_failed` diagnostic. The status does not
+establish the underlying cause or guarantee that retrying will succeed.
+
 Hopper metadata and package downloads require HTTPS throughout the redirect
 chain; a redirect to HTTP is refused before that destination is requested.

@@ -825,9 +855,13 @@ stage `connection`.
 If macOS denies Apple Events, allow the application that starts REA under
 **System Settings → Privacy & Security → Automation**, then retry. REA releases
 the target reservation when the native helper reports its complete authorization
-rejection and its arguments cannot alter the helper's generated AppleScript.
-Arguments containing quotes, backslashes, or line breaks remain unchanged but
-cannot establish that a failed handoff opened no document. Other failed handoffs
+rejection after literal argument admission. Before application handoff, REA refuses
+double quotes, backslashes, or line breaks in the final launcher path or arguments,
+with `details.launch_rejection.boundary: "argument_encoding"` and the affected source/index.
+Select literal-safe launcher/runtime paths and loader arguments, or another
+compatible provider. REA preserves original file names and evidence: a quoted
+executable name can still work when its prepared image path is literal-safe;
+database paths must themselves be representable. Other failed handoffs
 retain ownership until document closure is confirmed. If a timed-out bridge
 becomes ready later, `close_binary` connects to that run, authenticates its
 identity, and requests document shutdown. Once its listener is ready, the bridge
@@ -894,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.
@@ -966,7 +1005,7 @@ copying license secrets into logs, or killing unrelated Hopper processes.

 REA connects to an existing Ghidra installation on Linux x64/arm64, macOS x64/arm64,
 or experimental Windows x64 P0.
-It accepts Ghidra 12.1.x and the 64-bit full JDK declared by that installation's
+It accepts Ghidra 12.x (>=12.1) and the 64-bit full JDK declared by that installation's
 `application.java.min` and `application.java.max`. The JDK's reported platform must also
 map to the same native decompiler directory as the host: a JDK running under
 emulation (for example x86_64 under Rosetta on Apple silicon) or reporting a
@@ -974,7 +1013,8 @@ non-host `os.name` fails the doctor
 even when it is an otherwise accepted 64-bit full JDK. Select a matching JDK
 through `JAVA_HOME`; adding another decompiler in the JVM-selected directory
 does not satisfy this host-validated admission rule. Current 12.1 releases require
-JDK 21 or newer and set no maximum. The bridge is verified with Ghidra 12.1.4
+JDK 21 or newer; Ghidra 12.2 declares JDK 25 or newer. Neither sets a maximum.
+The bridge is verified with Ghidra 12.1.4
 and JDK 21. Each installation must include the native decompiler for the host
 architecture in `Ghidra/Features/Decompiler/os/<platform>/` or the corresponding
 `build/os/<platform>/` directory. Linux ARM64 uses `linux_arm_64`; official
@@ -985,7 +1025,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
@@ -1064,14 +1104,15 @@ rea providers --json
 ```

 `rea setup` can configure supported Windows agents and install the bundled
-REA skill after approval. Direct registrations use Node to launch REA's entry
-script; package-runner registrations use the pinned `npx` or `bunx` command. Hopper
+REA skill after approval. Managed registrations use the absolute selected Node or
+Bun runtime and REA entry script, including when setup ran through a package runner. Hopper
 installation remains unavailable on Windows. Setup never installs Ghidra,
 Java, or Python. It preserves valid detected Ghidra/JDK settings in agent
 registrations. See [Windows Ghidra P0](windows-ghidra-p0.md) for provider diagnostics.

-The separate `rea mcp add` builtin currently uses Incur's package-runner child
-launcher, which can fail on Windows with `MCP_ADD_FAILED: spawn npx ENOENT`
+The separate `rea mcp add` builtin delegates most clients to Incur's package-runner
+child launcher. Run that acquisition from a trusted directory; prefer managed
+`rea setup` when supported. That child launcher can fail on Windows with `MCP_ADD_FAILED: spawn npx ENOENT`
 before registering a client. REA's setup path is unaffected. For a client supported
 by setup, review `rea setup --client opencode --skill=false --dry-run --json`
 (substitute its client ID), then use the same scoped command without `--dry-run`
@@ -1089,7 +1130,7 @@ the application metadata and headless launcher. An explicitly supplied
 REA reports that error instead of silently selecting another installation.
 This discovery is read-only and does not execute the Ghidra launcher.

-Doctor validates the platform, architecture, Ghidra 12.1.x application version,
+Doctor validates the platform, architecture, Ghidra 12.x (>=12.1) application version,
 `support/analyzeHeadless` or `support/analyzeHeadless.bat`, the installation's
 Java major range, 64-bit JDK bitness, and the presence of `javac`/`javac.exe`.
 It also checks that the reported JVM `os.arch` and `os.name` map to the same native decompiler
@@ -1145,9 +1186,10 @@ This coordinate selects only REA's session-private configuration directory, not
 the installation or an existing user configuration directory.

 Each verified session uses an ephemeral temporary project and isolated
-home/cache/config/temp paths. REA passes `-readOnly`, `-deleteProject`, uses
-Ghidra's default analysis settings, and loads its packaged Java
-bridge via `-scriptPath`; it never opens an existing user project. Linux and
+home/cache/config/temp paths. By default REA passes `-readOnly`, `-deleteProject`,
+uses Ghidra's default analysis settings, and loads its packaged Java
+bridge via `-scriptPath` into a new ephemeral project; opt-in
+[existing-project reuse](#reuse-an-existing-ghidra-project) opens only an owned copy. Linux and
 macOS use a current-user-only local bridge socket and descriptor. The
 project remains under the selected temporary directory. If its Unix socket
 pathname would exceed the host's byte limit, REA allocates a separate owner-only
@@ -1166,7 +1208,7 @@ original process owner for a later cleanup retry.
 The experimental Windows transport uses authenticated IPv4 loopback with a
 private native-owned bearer descriptor and Job Object process ownership.

-Operations begin only after default auto-analysis completes. `open_binary`
+In the default fresh-import mode, operations begin only after default auto-analysis completes. `open_binary`
 selects and validates the target/provider binding; it does not wait for Ghidra
 import and auto-analysis. The first Ghidra-backed query starts that work lazily.
 The provider startup deadline is 330,000 ms by default for import, analysis,
@@ -1297,6 +1339,63 @@ not needed for the make step, only for the Ghidra provider. If your toolchain
 rejects the inherited `-mmacosx-version-min=10.6` flag, retry the make with
 `ADDITIONAL_FLAGS="-w"`.

+### Reuse an existing Ghidra project
+
+For repeated investigations, select an expanded local project marker with
+`REA_GHIDRA_PROJECT_PATH=/absolute/projects/app-analysis.gpr`. Both CLI and MCP
+use this shared selection. `REA_GHIDRA_PROGRAM_NAME` selects one exact program
+in the project root; when omitted it defaults to the selected target's filename.
+Paths, globs and command flags are not program names. The matching `.rep`
+directory must be present; restore `.grez` archives with Ghidra first.
+
+```bash
+export REA_ANALYSIS_PROVIDER=ghidra
+export REA_GHIDRA_PROJECT_PATH=/absolute/projects/app-analysis.gpr
+export REA_GHIDRA_PROGRAM_NAME=app
+rea decompile /absolute/target/app --procedure entry --provider ghidra --json
+```
+
+Set the same variables in the MCP server environment and restart/reconnect;
+`open_binary` still selects the original target file. `rea setup` retains these
+explicit settings in a saved registration. Fresh import remains the default
+when the project setting is absent. This route supports native ELF, PE and
+Mach-O programs on POSIX without provider-pinned import preparation; Windows,
+raw/DOS/DOL and special pinned-language import profiles require fresh import.
+
+REA fingerprints only the selected `.gpr`/`.rep` pair, copies it into its owned
+runtime, verifies the copied content against the committed analysis profile,
+and runs `-process <program> -noanalysis -readOnly`. Ghidra never opens or saves
+the original database; REA reads selected files only for fingerprinting and copying.
+This mode does not copy unrelated sibling projects, rerun repair scripts, or
+admit bridge database edits. Cleanup removes the owned copy.
+The bridge checks the program's recorded import SHA-256 against the admitted
+target digest; mismatches and project changes fail explicitly. Reopen the target
+to resolve a new profile after intentionally changing the source project.
+
+The profile records the caller path, resolved project/name, program and content
+fingerprint. Original analysis settings and completeness remain **unknown**;
+prior annotations or edits are caller-project state, not fresh REA discoveries.
+A matching recorded import digest does not claim that the database is unedited.
+Saved REA seed/analyzer reports remain historical facts in retained source Evidence;
+they are not interpreted as overrides applied by this session.
+Project content participates in snapshot identity, so different project states
+cannot reuse the same profile's cached observations.
+
+To prepare a new project explicitly, use your existing Ghidra installation in a
+new directory you own (this writes that project; REA does not save it for you):
+
+```bash
+mkdir /absolute/new-projects
+GHIDRA_HEADLESS_MAXMEM=1536M JAVA_TOOL_OPTIONS=-XX:ActiveProcessorCount=2 \
+  "$GHIDRA_INSTALL_DIR/support/analyzeHeadless" /absolute/new-projects app-analysis \
+  -import /absolute/target/app -analysisTimeoutPerFile 600 -max-cpu 2
+```
+
+Check that preparation completed successfully before selecting the project.
+Preparation time, disk copy/fingerprinting, engine startup and client deadlines
+are separate costs; reusing a project avoids import/analysis, not all startup.
+Use the [heap/CPU controls](#ghidra-heap-and-cpu-controls) appropriate to the target.
+
 ### Ghidra import language and analysis seeds

 Ghidra detects the language from the executable header. To set it (for example, Borland C++ PE images):
@@ -1351,6 +1450,21 @@ current setting. For Windows PE resource analysis, the exact name is
 `WindowsResourceReference`. Disabling an analyzer skips the facts it would have
 produced.

+Ghidra's Objective-C Message Analyzer can log
+`Required Objective-C data type not found in data type manager` /
+`Try adding libobjc.dylib` when a Mach-O links Objective-C runtime symbols but
+defines no class metadata (thin Cocoa glue in a C++ binary is a common case).
+That text is non-fatal Ghidra analyzer output: auto-analysis continues, and the
+analyzer simply skips `objc_msgSend` call-target recovery. REA's headless import
+does not accept a "add this library" option, and on modern macOS
+`/usr/lib/libobjc.A.dylib` exists only in the dyld shared cache, so there is no
+on-disk library to add. Treat the line as a coverage limitation, not an REA
+failure; check the session's `failure_kind` (and related provider errors) for
+any real abort. To silence that analyzer, set
+`REA_GHIDRA_DISABLED_ANALYZERS="Objective-C Message Analyzer"`. For large
+executables that miss the startup deadline instead, raise
+`REA_GHIDRA_STARTUP_TIMEOUT_MS` and the [Ghidra heap](#ghidra-heap-and-cpu-controls).
+
 ### Ghidra heap and CPU controls

 Set resource controls in the environment that launches the CLI or MCP server,
@@ -1446,12 +1560,93 @@ 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
 Ghidra/JDK installation; neither is inferred from startup alone.

+## Agent plugins and marketplaces
+
+REA's npm package is the shared Claude Code and Codex plugin artifact. It
+contains `.claude-plugin/plugin.json`, `.codex-plugin/plugin.json`, and the
+canonical generated `skills/` tree. Both manifests select `./skills` and run a plain Node bootstrap pinned to
+that exact package version. The client must have a supported standalone `node`
+on its PATH. Claude expands its documented `CLAUDE_PLUGIN_ROOT` in the script
+argument; Codex resolves `cwd: "."` from the installed plugin root before
+launching the relative script. The bootstrap verifies the package version and runs its bundled runtime in
+the same process, preserving stdio and REA's provider/worker cleanup. It does
+not start another package runner or download a different runtime. The existing release skill
+generator also pins CLI recovery commands to the same version.
+
+The repository's single-plugin marketplaces are declared in
+`.claude-plugin/marketplace.json` and `.agents/plugins/marketplace.json`.
+Both select an exact `rea-agents` npm version instead of mutable source-checkout
+contents. Release Please updates their selectors alongside the plugin manifests.
+No plugin-only publication or generated skill files committed to Git are needed.
+The qualified release archive contains a runtime-only manifest and
+`npm-shrinkwrap.json` plus bundled runtime dependencies, including PTY packages
+for each supported OS and CPU; development dependencies and development-only overrides
+stay in the source manifest and lockfile. Both clients receive this same archive.
+
+This distribution becomes installable after the first qualified npm release
+containing these plugin manifests. Earlier published packages are not changed
+by this source proposal. For local source development, run `npm ci && npm run build:cached` to generate
+the runtime and packaged skill before loading the repository as a plugin.
+A source plugin uses the locally built runtime and generated skill; rebuild after
+source changes. Missing builds and mismatched version pins fail with an actionable
+error. The authored `.agents/skills/` tree is not the plugin's shipped skill layout.
+Windows source workflows that need native controls still require the
+[Windows source-checkout build](https://github.com/morluto/rea/blob/main/native/windows/README.md#build).
+
+In Claude Code:
+
+```text
+/plugin marketplace add morluto/rea
+/plugin install rea@rea
+```
+
+In Codex CLI, add the marketplace and install REA:
+
+```bash
+codex plugin marketplace add morluto/rea
+codex plugin add rea@rea
+```
+
+Each release updates both manifest versions and their pinned server version
+together, which is when installed copies refresh the bundled skill and move to
+the new server. A plugin does not run `rea setup`, so provider
+configuration still follows the sections above. Use the plugin or a
+`rea setup` registration for a client, not both, to avoid two `rea` servers.
+
+`rea doctor` does not see plugin-owned state. Its client and skill checks read
+only the registrations and skill locations that `rea setup` manages, so for a
+plugin-only install `rea doctor --client <id>` and `rea doctor --skill` report
+`missing` and recommend `rea setup`. Do not follow that remediation. Check the
+plugin with the client instead (`claude plugin list` and `/mcp` in Claude
+Code, `codex plugin list` in Codex).
+
+For analysis engines, ask the connected server: have the agent call
+`binary_session` and read `result.tool_availability`, which reports what the
+server the plugin started can use, with reasons and remediation. See
+[MCP contracts](mcp-contracts.md).
+
+A plugin does not put `rea` on your `PATH`. To check an engine from a
+terminal, use the package runner at the version the plugin pins:
+
+<!-- x-release-please-start-version -->
+
+```bash
+npx -y rea-agents@6.8.0 doctor --provider ghidra --json
+```
+
+<!-- x-release-please-end -->
+
+If your installed plugin is older, use the version in its manifest instead.
+That report describes the terminal's environment, not the plugin server's.
+The server inherits the client's environment, so a setting such as
+`GHIDRA_INSTALL_DIR` that exists only in your terminal does not reach it.
+
 ## MCP Registry

 REA is published in the official MCP Registry as `io.github.morluto/rea`. Registry
@@ -1462,40 +1657,45 @@ For a client that supports Registry discovery, search for `io.github.morluto/rea
 and select the npm package. The published metadata launches the existing stdio
 server through `npx` with the `mcp` command.

-For a client that requires manual configuration, use:
+For supported clients, prefer `rea setup`: it records the absolute JavaScript
+runtime and entry script of the REA installation performing setup. Client starts
+then use that installation directly, keeping the client's working directory
+without running npm or Bun package resolution there. Registry clients control
+their own package acquisition; Registry metadata cannot name local absolute paths.

-<!-- x-release-please-start-version -->
+For manual stdio configuration, substitute the absolute paths of an existing
+installation (use the command shown in a setup dry-run):

 ```json
 {
  "mcpServers": {
    "rea": {
-      "command": "npx",
-      "args": ["-y", "rea-agents@6.8.0", "mcp"]
+      "command": "/absolute/path/to/node",
+      "args": ["/absolute/path/to/rea/scripts/rea.mjs", "mcp"]
    }
  }
 }
 ```

-<!-- x-release-please-end -->
+Run current setup to migrate recognized older `npx`/`bunx` registrations, with
+backups, then restart the client. Unrelated or unidentified registrations remain
+untouched. Setup does not prewarm a separate package-runner command.

-Persistent registrations should use one exact package version. `rea setup`
-writes the same package-runner shape, or `bunx rea-agents@<version> mcp` when
-setup runs through `bunx`, and pins it to the exact version that performed
-setup. Run current setup to refresh an older registration, then restart the
-client.
-
-Package runners key their package cache by the requested spec, so the entry
-installed for the `@latest` invocation that ran setup cannot serve the pinned
-registration. Setup therefore materializes the pinned entry once, best-effort
-with a bounded timeout, before finishing. When that step cannot run, for
-example offline, the first client start performs the one-time install inside
-the client's MCP startup deadline and may need one more restart.
+If setup itself runs from a package-runner cache, the registration depends on
+that cache entry and the selected runtime remaining installed. Removing either
+makes startup fail; it does not download or resolve another package. Restore the
+same installation and rerun setup. Changing package requests, cache roots, or
+runtimes can create a different installation identity. If the old entry cannot be
+identified, restore it first or manually remove the confirmed REA registration
+before running setup again. A global installation provides a more durable path.

 ## Package runners and global installation

-A package-runner invocation can use a REA version installed in the current project. To
-request the latest release explicitly, use:
+Package runners can select project-local packages and read project configuration,
+even for explicit version requests. Acquire REA from a trusted working directory,
+outside the target project, and pass absolute target paths to analysis commands.
+REA cannot validate package acquisition that happens before its entrypoint starts.
+To request the latest release explicitly, use:

 ```bash
 npx rea-agents@latest setup
@@ -1512,16 +1712,14 @@ For an intentional rollback, make the package request explicit:
 npm exec --yes --package=rea-agents@2.4.0 -- rea setup
 ```

-Setup continues to pin persistent MCP registrations to the exact version that
-performed setup. Running current setup later migrates unversioned or older
-managed registrations through the normal reviewed setup transaction.
+Setup binds persistent MCP registrations to the installation that performed setup.
+Running current setup later migrates recognized legacy package-runner registrations
+through the normal reviewed setup transaction.

 With Bun, `bunx rea-agents setup` (or `bunx rea-agents@latest setup`) is the
-equivalent entry point. Setup run through `npx` registers
-`npx -y rea-agents@<version> mcp`; setup run through `bunx` or `bun x` registers
-`bunx rea-agents@<version> mcp`. On Windows, setup wraps either command in
-`cmd.exe /d /c` so clients can start the runner's command shim. Neither
-registration points into the runner's temporary package cache.
+equivalent acquisition entry point. Managed registrations use the selected Bun
+executable and REA entry script directly. Windows registrations likewise use
+absolute runtime and script paths, without a package-runner command shim.

 REA supports Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), and 26.12.1+. Node.js 23, 25, earlier 26.x releases, and prereleases are unsupported. It uses the npm already paired with that runtime and never upgrades Node.js, npm, or Homebrew.

@@ -1555,8 +1753,9 @@ Review the plan, approve the selected client changes, then restart those clients
 This registers the installed entrypoint directly; installing the global package
 alone does not replace existing `npx` registrations. Each client still has its own
 REA process and analysis state. Direct registrations follow the installed CLI;
-use `rea update` to update it. Running setup through `npx` again selects the pinned
-package-runner command. Do not register paths inside npm's temporary package cache.
+use `rea update` to update it. Running setup through `npx` again selects the
+installation that executes setup, potentially in npm's temporary package cache;
+retain that cache entry for as long as the registration uses it.

 ### npm workspace errors before REA starts

@@ -156,6 +156,21 @@ Select one literal seed kind: node ID, route, string, API, IPC channel, module,
 or native export. Matching is exact or literal substring matching; regular
 expressions and executable predicates are not accepted. The trace includes all
 matching seeds and the complete graph reachable in the selected direction.
+`both` follows relationships in either direction, except that a container
+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
@@ -183,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,
@@ -205,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
@@ -269,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
@@ -72,6 +72,18 @@ code-point order. Dependency manifests remain package observations but do not
 declare Electron main or renderer entries. If only dependency manifests are
 present, the inventory artifact remains the graph root.

+Package observations use `renderer_declarations` to record the actual present
+fields: strings, including empty strings, remain exact; non-string values use `{ "status": "non-string" }`
+without copying nested browser mappings. An empty record means no such fields
+were present; `null` means package metadata was invalid or unavailable. Renderer
+role mechanisms and package load edges name the field that supplied the candidate,
+selected as the first nonempty string from `renderer`, `browser`, then `module`.
+The package load edge retains `declared_path`, `source_field`, and resolution
+facts for that selection. New analyses no longer emit the derived package
+`renderer` alias; consumers must read declarations for source metadata and load
+edges for the selected candidate. Previously retained Evidence keeps its original
+properties and remains readable without migration.
+
 ## Select sources before analysis

 For a question about known entry sources, supply exact artifact-relative file
@@ -239,10 +251,12 @@ An unpacked entry whose companion bytes were not supplied remains
 `unavailable`. REA continues analyzing embedded JavaScript and records the
 missing native/resource bytes as unknown. The occurrence keeps
 `hash_status: unavailable`; no content-addressed child artifact is created for
-those missing bytes. New inventories preserve an ASAR companion declaration as
-`unpacked: true`; an omitted flag in an older inventory does not establish that
-unavailable bytes belonged to a companion. See [MCP integrity handling](mcp-contracts.md#integrity-record-and-continue)
-for the tool-result contract.
+those missing bytes. New ASAR file occurrences record `unpacked: true` for
+companion files and `unpacked: false` for packed entries, including when the
+file bytes are unavailable. An omitted flag in an older inventory remains
+unknown; it does not establish either storage mode. See
+[MCP integrity handling](mcp-contracts.md#integrity-record-and-continue) for the
+tool-result contract.

 JavaScript whose syntax cannot be parsed retains unavailable semantic coverage
 with `incomplete-module` unknowns for each semantic family and unknown omitted
@@ -350,6 +364,13 @@ Selected bounded text is then parsed as inert data to recover:
  relative to the calling module; string worker and service-worker paths use
  the document base URL or Node's working directory, which static analysis
  does not establish, so they keep their expression and stay unresolved);
+- Vite preload dependency tables (`__vite__mapDeps`): `./` entries resolve
+  relative to the importing chunk; base-relative entries such as
+  `assets/chunk.js` carry a `vite-output:` specifier and resolve under the one
+  ancestor directory of the importer that holds them, the build output
+  directory. A file found there but not analyzed, such as a stylesheet, stays
+  `unavailable` with its path. Selecting only the assets directory leaves them
+  `not-found`;
 - route, network endpoint, storage, and vendor-marker observations;
 - local source-map declarations and original
  source names and content digests;
@@ -426,8 +447,17 @@ and links whose callee was renamed by a minifier are not recognized.
 Bundler adapters own callback roles: Webpack supplies module, exports, then
 loader; esbuild CommonJS supplies exports, then module. Export extraction uses
 those binding identities for assignments and declarations, so renaming either
-parameter does not change the recovered names. Global property-definition
-intrinsics require lexical and visible-write proof. Factory export declarations
+parameter does not change the recovered names. The convention always supplies
+every role argument, so a role parameter's default never runs: a defaulted
+module or exports parameter keeps its role, and the default expression yields
+no exports, references or chunk keys. `{exports: alias}` in the module position
+binds `alias` to `module.exports`.
+Other role patterns, such as rest, array, nested or computed-key patterns or a
+non-identifier loader, receive no role and count as unknown findings, so the
+file's analysis is partial rather than an exact empty export list. An
+export-shaped write through a role binding whose value at that read cannot be
+ordered against a replacement is also an unknown finding. Global
+property-definition intrinsics require lexical and visible-write proof. Factory export declarations
 also require the loader's `d` member to have no prior or unordered visible
 replacement, including writes through lexical aliases. Unrelated loader members
 do not invalidate declarations. Ordering describes declarations within one factory
@@ -530,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
@@ -612,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
@@ -25,18 +25,50 @@ Keep the original analysis inputs in that call. For the CLI, pass the same
 selection as `--view '<JSON>' --detail summary --evidence_output routes.json`.
 The complete Evidence bundle is written without overwriting existing files.
 Unselected delivery retains the existing complete result. A web-bundle summary
-requires an explicit route view; application summaries also support the existing
+requires an explicit route or web-bundle view; application summaries also support the existing
 general summary when `view` is omitted.

 Use the returned `normalized_result.parent_evidence_id` with
 `inspect_analysis_view` on the same connection. The CLI's exported bundle can be
 reopened with `inspect-evidence-bundle`; its `records` contain the complete
-Evidence. To use `inspect_analysis_view`'s `evidence-file` source, extract the
-selected parent record into a separate local Evidence JSON file (that source
-accepts one Evidence record, not a bundle). Views do not reopen source files or
+Evidence. `inspect_analysis_view`'s `evidence-file` source accepts either one
+Evidence record or an exported bundle with the selected `evidence_id`.
+Views do not reopen source files or
 reconnect to a browser. Historical Evidence without `route_inventory` is
 unmeasured, rather than an empty route set.

+## Page captured endpoint observations and inferences
+
+For `analyze_web_bundle`, select `detail: "summary"` and
+`view: {kind: "web-bundle", collection: "endpoints", limit: 32}`. The CLI
+accepts the same JSON through `--view`, with `--detail summary` and
+`--evidence_output bundle.json`. Query the returned parent with
+`inspect_analysis_view` to read `endpoints`, `inferences`, or `summary` without
+recapturing the page or repeating JavaScript analysis.
+
+Both row collections accept exact `indices`, `values`, `script_keys`, `fields`,
+`offset`, and `limit`; endpoints also accept `mechanisms`, and inferences accept
+`kinds`. Filters combine with AND, and an explicit empty selector matches no
+rows. Every row retains its `source_index` in the original collection, including
+when other fields are omitted. This identity is scoped to the parent Evidence
+and collection. Original ordering and separate occurrences of duplicate values
+are preserved; request endpoint `location` or inference `basis` for source details.
+
+Follow `coverage.next_offset` until `coverage.exhausted`; those fields describe
+the selected rows, independently of producer `completeness`. Each response also
+preserves structured `source_unknowns`, including `affected_script_keys`, so a
+filtered or value-only page cannot hide a source gap. The summary's
+`limitation_count` counts distinct parent and report limitations before display
+bounding. An `endpoint_candidate` remains an inference, with its original
+confidence and basis, and does not prove a backend endpoint or reachability.
+
+Pages obey the shared 1 MiB projection budget; MCP transport applies its own
+wire-size guard. A byte-limited page returns a continuation; an indivisible
+oversized record or metadata returns a typed resource error. Select fewer
+fields or retrieve the complete retained parent through `get_evidence_bundle`,
+`export_evidence_bundle`, or the CLI's exported bundle. Full Evidence is never
+silently truncated.
+
 Collections are `summary`, `routes`, `occurrences`, `sources`, and `unknowns`.
 All row collections support exact batch `where.ids`, field selection, `offset`,
 and `limit`. An explicit empty filter array matches nothing. Routes also support
@@ -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.
@@ -63,7 +63,7 @@ All four preserve target-file bytes. `open_jeb_project` selects or creates an en
 - The engine caps `list_units` pages at 100; a full page is reported as `coverage: "partial"` because more units may exist. An empty remainder is `complete` only when fewer units than requested were returned.
 - When `decompile_jeb_item` omits `unit_path`, the engine implicitly selects the project's first code unit; REA reports `unit_path: null` and a limitation instead of guessing the effective unit.
 - `item_address` is a JEB code-item reference, such as a value returned by the engine's `list_code_items`. Preserve that representation and select its code unit explicitly. For the audited CE SQLite unit, the exported method reference was `sqlite3_libversion_number`; using its raw ELF symbol address did not produce a successful decompilation. File offsets, ELF virtual addresses and engine item references have different semantics. REA currently exposes unit listing, while code-item discovery remains an upstream JEB operation.
- Engine refusals (`success: false` envelopes) are preserved as unsupported-target errors carrying the engine's own message, for example a nonexistent item address.
+- Valid engine refusals (`success: false` envelopes) return `execution_failure` with the engine's message when available. Diagnostics preserve the original envelope, including any recovery advice, and the inputs of a refused primary request. If client metadata fails after a primary reply, that reply and the caller's inputs remain in partial Evidence. REA does not infer an unsupported target from a refusal, invoke a recovery tool, or retry the request.
 - Successfully parsed client information is reused for the lifetime of the MCP connection, including when the engine omits its version. Explicit client inspection and availability probes refresh it.
 - An unreachable endpoint is a provider-availability failure with recovery guidance; REA does not retry or spawn the engine.

@@ -125,7 +125,19 @@ REA writes Kuna's exports only inside `REA_KUNA_CACHE_DIR`:
 - `trash/` holds retired builds and evicted exports awaiting removal.
 - `home/` is Kuna's HOME.

-Builds publish by one rename, so a reader sees a complete export or none. If later staging retirement fails, the typed cleanup error retains the completed export's key, directory and manifest in `published_export`. The session adopts that verified project; later queries reuse its immutable files while `project_export.cleanup_incomplete` reports the retained owner's live state. `close_binary` retries only the remaining cleanup, and a successful retry resolves prior cleanup errors. A failed export followed by failed staging cleanup retains both failures; it does not invent a publication receipt. A session keeps the export it uses from eviction only within its own REA process. If another REA process sharing the cache evicts it, the session rebuilds it; meanwhile pseudocode falls back to single-function runs. A damaged or edited export is removed and rebuilt. Staging moves to `trash/` for removal only after REA proves its Kuna process stopped. Staging of a process it cannot prove stopped is never swept; REA keeps it owned, retries the stop on `close_binary`, and reports it until the stop is proven. Failed file removal also stays bound to its export and is retried by `close_binary`; closing does not report success while that cleanup remains. `rea doctor --provider kuna` reports the cache directory without creating it.
+The cache key includes the selected launcher and resolved executable paths, plus
+the target's native basename: that name determines the export filenames and
+appears in generated source. REA accepts one current manifest layout. Older
+exports are rebuilt on demand and retired through normal owned-cache cleanup;
+no manual deletion or migration is needed. Manifests must name the producer's
+exact flat file layout, with matching basenames and producing inputs. Replaced
+entry, project or manifest symlinks are refused before their targets are read;
+an unverified `projects/` parent grants no removal authority. Warm reuse checks
+the manifest's file identity as well as the export files. These refusal and
+migration cases are verified with controlled Kuna-format exports; they do not
+establish behavior of an independently installed Kuna release.
+
+Builds publish by one rename, so a reader sees a complete export or none. If later staging retirement fails, the typed cleanup error retains the completed export's key, directory and manifest in `published_export`. The session adopts that verified project; later queries reuse its immutable files while `project_export.cleanup_incomplete` reports the retained owner's live state. `close_binary` retries only the remaining cleanup, and a successful retry resolves prior cleanup errors. A failed export followed by failed staging cleanup retains both failures; it does not invent a publication receipt. A session keeps the export it uses from eviction only within its own REA process. If another REA process sharing the cache evicts it, the session rebuilds it; meanwhile pseudocode falls back to single-function runs. A damaged or edited export is removed and rebuilt. REA retains the file state verified with each digest, checks it before warm-cache reuse, and checks open descriptors before and after reading text. Assembly indexes are checked against the same state; a changed file makes the whole report retry rather than mixing facets from different exports. Staging moves to `trash/` for removal only after REA proves its Kuna process stopped. Staging of a process it cannot prove stopped is never swept; REA keeps it owned, retries the stop on `close_binary`, and reports it until the stop is proven. Failed file removal also stays bound to its export and is retried by `close_binary`; closing does not report success while that cleanup remains. `rea doctor --provider kuna` reports the cache directory without creating it.

 ## Verify with a real Kuna

@@ -120,6 +120,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 +211,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 +480,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
@@ -660,13 +718,15 @@ name and raw signature digest available while marking that signature malformed
 and coverage partial.
 A fat method header's nonzero LocalVarSigTok must name an existing StandAloneSig
 row whose blob is a structurally valid LocalVarSig. REA validates its local
-types and exact blob coverage but does not project their identities. An invalid
+types and exact blob coverage, retaining `local_var_signature` with the raw blob
+digest and whether named types, modifiers, or generic variables require metadata
+or declaring context. Historical Evidence defaults this field to null. An invalid
 token or malformed signature leaves decoded CIL anchors intact but marks the
 body malformed and coverage partial. Unsupported local type encodings retain
 the readable body with partial coverage. Zero continues to mean no locals
-signature. Comparison detects whether a locals declaration is present, but raw
-table tokens are not cross-build identities and local type contents are not
-compared.
+signature. Raw table tokens are not cross-build identities. Comparison uses
+validated context-free signature digests; signatures requiring metadata or
+declaring context remain unknown across artifacts.

 ## Decoded-CIL fingerprint

@@ -868,9 +928,14 @@ MethodDef flags or implementation flags value differs, including accessibility
 or synchronization changes. Observed method-body `init_locals` and `max_stack`
 differences also contribute to `metadata`, even when CIL decoding is incomplete.
 For complete bodies, presence or absence of a locals signature also contributes;
-the locals table token is build-local and is not compared. Local type contents
-are not currently compared, so this facet does not establish equivalent locals
-declarations.
+the locals table token is build-local and is not compared. Different validated
+context-free LocalVarSig digests report a metadata encoding difference without
+asserting a semantic type change. Equal digests establish unchanged bytes only
+when neither signature requires metadata or declaring context. Historical
+unrecorded signatures and context-dependent signatures keep local identity
+unknown, preserving any independently observed changes. The same method token
+in an artifact with the same authenticated SHA-256 identifies the same local
+signature bytes, including for retained historical Evidence.
 An unavailable header value keeps body coverage unknown rather than establishing
 equality or a difference. These comparisons are separate from the CIL/signature
 matching tiers: identical instructions do not establish unchanged method metadata.
@@ -26,6 +26,23 @@ 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, 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
 `detail`, it retains the complete dossier in the session and returns
 `inspect_analysis_view` summary Evidence whose
@@ -52,13 +69,14 @@ 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. 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
@@ -159,8 +177,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.
@@ -242,6 +265,36 @@ to `/absolute/view-request.json`, then run
 `rea inspect-analysis-view /absolute/view-request.json --json`. This also reads
 pre-summary source records without changing their identity; no live provider is started.

+`procedure_address`, `procedure_callees`, `procedure_callers`,
+`resolve_containing_procedure` and `get_call_graph` also accept `detail: "summary"`
+(complete remains the default). The summary includes the first 64 recorded
+observations, exact source parameters and provider/profile identity, relationship
+coverage where recorded, and the retained complete parent's ID. Continue with
+`view: {"kind":"native-observation","offset":64,"limit":64}`. Array positions
+retain `source_index`; graph rows additionally retain their original `level`.
+Graph pages order levels by Unicode code point and keep original row order within
+each level. A recorded empty level is a `status: "empty-level"` row with
+`source_index: null`; observation counts include these markers. Graph diagnostic,
+limitation and reason IDs index that page's `items.messages` dictionary. Expand
+those references to recover exact text, repeated messages, and absent versus
+empty optional fields. Failed nodes retain their original error.
+
+These views reference complete source context through `source_context.digest`
+and caveat counts. Read it using the same parent with
+`view: {"kind":"native-context","facet":"overview"}`. The other facets are
+`analysis-profile`, `limitations` and `result-limitations`; all accept `offset`
+and `limit`. Overview includes source subject, provider, authority, execution
+environment and profile digest. Full profiles and caveat text remain accessible
+without repeating them in every fact response. Context digests follow Evidence's
+semantic subject identity, so caller-selected path aliases preserve context
+identity while responses retain the selected display path. A null profile means
+unavailable; null result-limitations means not applicable to a primitive and
+is distinct from an observed empty graph limitation list. Until the source
+caveats have been inspected, interpretations beyond the returned facts remain
+unknown. Exhausted pages describe the recorded observations and do not establish
+complete native discovery. The same views work through the CLI with historical
+Evidence files or bundles and require no live provider.
+
 For oversized native function Evidence, `details.reported_limits.continuation`
 contains a ready-to-call `inspect_analysis_view` request for the retained
 pseudocode's first page. Use its `name` and `arguments` directly, then follow
@@ -267,6 +320,15 @@ unknown metadata. Missing omission counts remain null. Summary output carries
 every matching record; actual transport admission still applies. Omitted
 `detail` preserves complete canonical bundle delivery; filters require summary.

+Residual-unknown mutations reject missing Evidence or unknown references and
+unproven verified resolutions with nonretryable `invalid_request` diagnostics.
+`details.constraint` carries the validator's `kind`, owning `unknown_id`, and
+missing `evidence_id` or `related_unknown_id` where applicable. Correct the
+reported input or supply the required retained Evidence; unchanged retries do
+not repair these constraints. Rejected mutations leave retained state unchanged.
+Revision conflicts remain retryable `revision_conflict`; broken revision histories
+remain `evidence_integrity_mismatch`.
+
 `list_unknowns` returns every matching current head by default. For a smaller
 inline response, supply `offset` and `limit`, then follow `next_offset` until it
 is null. `total` counts all matching heads; each page preserves complete records
@@ -286,8 +348,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`.
@@ -308,6 +373,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
@@ -343,10 +440,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
@@ -383,6 +482,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
@@ -498,10 +600,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
@@ -583,11 +687,22 @@ capabilities. The default result contains the complete inventory in groups that
 share status facts. `tool_availability.client_requirements` is the baseline for
 each group; a group's optional `client_requirements` replaces that baseline for
 the group's tools. Expand each group's `names` into one tool entry, carrying its
-surface, availability, reason, remediation, default-mode status, modes, and
-client requirements. Compare the union of group names with `tools/list` when
-checking that a client received the full catalog. An operation absent from all
-groups is missing from the complete inventory; it is not an implicit
-unavailable entry.
+availability, reason, remediation, default-mode status, modes, and client
+requirements. Compare the union of group names with `tools/list` when checking
+that a client received the full catalog. An operation absent from all groups is
+missing from the complete inventory; it is not an implicit unavailable entry.
+
+`detail` selects the projection and the result echoes it. The default
+`summary` keeps open state, target identity, the binding, current-route
+`capabilities`, run, activity and health status, and each provider candidate's
+identity, selection, and availability and target-support `status`, `code`, and
+`reason`. It lists the fields it leaves out in `omitted_fields`: provider
+`diagnostics`, candidate `capabilities`, and each tool group's static `surface`,
+`effects`, and `annotations`. Omitted fields are not empty or false.
+`detail: "complete"` returns them inline, groups tools by those flags too, and
+has no `omitted_fields`. The output schema keys each result's candidate,
+tool-group and omission fields by its `detail`. CLI `capabilities` and
+`providers` always return complete provider facts.

 `get_call_graph` and `trace_call_path` report `forward` and `backward` modes.
 Each requires `procedure_address` plus `procedure_callees` or `procedure_callers`,
@@ -600,8 +715,8 @@ finish without reading relationships, even when neither traversal mode is
 available. Discovery does not block that direct invocation or replace its typed
 partial/error outcomes.

-The `effects` and `annotations` arrays list the true members of their fixed
-vocabularies. A known member omitted from either array is false. This applies
+With complete detail, the `effects` and `annotations` arrays list the true
+members of their fixed vocabularies. A known member omitted from either array is false. This applies
 only to these closed flag sets; it does not make an omitted tool, provider, mode,
 or limitation false. Keep availability reasons, remediation, client-feature
 requirements, and mode facts inline with the grouped tool names. The optional
@@ -632,7 +747,8 @@ identity, availability, reason, rejection code, effects, and ordered
 limitations.

 `binary_session.analysis_provider_candidates` is authoritative for deep-engine
-discovery. Each candidate's capability sets describe that possible provider;
+discovery. Each candidate's capability sets, returned with complete detail,
+describe that possible provider;
 they do not select it. The top-level `capabilities` describe the current route,
 while `analysis_provider_binding` identifies the concrete selected route. These
 fields are not interchangeable. Target-free discovery is sorted by provider ID,
@@ -645,6 +761,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
@@ -687,6 +834,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
@@ -775,7 +938,12 @@ the bound address is local; names are added only after classifying the actual IP
 On such a bind, requests whose `Host` header is outside the SDK loopback allowlist plus
 the configured name and the bound address are refused with `403`, and a browser
 `Origin` outside that allowlist is refused the same way (a missing `Origin`
-passes); a non-loopback bind relaxes both checks and logs the relaxation. A reply sent before a request body was read (a refused `Host` or `Origin`, an unknown route, the startup `503`) closes the connection after the reply, so an unread upload cannot keep a socket open. Request targets are taken verbatim as origin-form paths (`//host/path` is a path, not another origin); an absolute-form target, a target containing a raw fragment delimiter (`#`), or one whose path URL parsing would rewrite (dot segments such as `/public/../mcp`), is refused with `400`, and a method Fetch does not support with `405`. Percent-encoded `%23` remains valid query data. Only an `initialize` object can replace an open session. A sessionless array containing initialize, including a one-element array, is refused with HTTP `400` before session creation or handover. Scoped
+passes). A non-loopback bind requires `MCP_ALLOWED_HOSTS`, or
+`--allowed-hosts` for `rea mcp --http`, listing every client host name or IP
+address. Configuration validates and canonicalizes complete tokens once;
+URLs, ports and empty entries are refused. Both Host and Origin checks remain
+active on that declared list. The announced URL uses the bound hostname if
+admitted, otherwise the first declared hostname, with the actual bound port. A reply sent before a request body was read (a refused `Host` or `Origin`, an unknown route, the startup `503`) closes the connection after the reply, so an unread upload cannot keep a socket open. Request targets are taken verbatim as origin-form paths (`//host/path` is a path, not another origin); an absolute-form target, a target containing a raw fragment delimiter (`#`), or one whose path URL parsing would rewrite (dot segments such as `/public/../mcp`), is refused with `400`, and a method Fetch does not support with `405`. Percent-encoded `%23` remains valid query data. Only an `initialize` object can replace an open session. A sessionless array containing initialize, including a one-element array, is refused with HTTP `400` before session creation or handover. Scoped
 IPv6 literals (`fe80::1%eth0`) are refused before binding, because no URL can
 name them. Listener errors reach the runtime's connection-loss handler only
 after a successful bind; a bind failure prints the listen-failure message alone. Request bodies are bounded by the SDK's
@@ -958,6 +1126,12 @@ A successful MCP initialize handshake establishes the REA connection.
 that Ghidra has finished importing the target. The first Ghidra-backed query,
 such as `binary_overview`, starts the engine and waits for import, default
 auto-analysis, bridge connection, and health readiness before returning analysis.
+With `REA_GHIDRA_PROJECT_PATH`, shared CLI/MCP configuration instead selects an
+[existing project copy](installation.md#reuse-an-existing-ghidra-project), whose
+content fingerprint is committed into the profile. Import, auto-analysis and
+repair scripts are skipped; original analysis completeness/settings stay unknown,
+and bridge database edits are unavailable. The same startup/client deadlines
+still cover copy verification, engine launch and the authenticated handshake.

 These deadlines have different owners:

@@ -1153,7 +1327,18 @@ attachment. Native checksum verification failures still refuse traversal;
 Occurrences use normalized logical paths for identity and lookup. Optional
 `source_path` retains the original path within the owning reader when Unicode
 NFC or reader admission changes its spelling; it is source evidence, not an
-output destination. POSIX letter-colon names such as `a:b` remain valid logical
+output destination. New ASAR file occurrences explicitly record the boolean
+`unpacked`: `true` identifies a companion file and `false` identifies a packed
+entry. This field describes archive storage, independently of whether the bytes
+were available or passed integrity verification. Older occurrences may omit it;
+omission remains unknown and must not be defaulted to `false`. Consumers that
+previously accepted only literal `true` must also accept `false`, while retaining
+support for omitted historical values.
+`compare_artifacts` reports a metadata change when both storage values are
+known and differ. If only one value is known, storage comparison is unknown;
+when both are omitted, storage is not compared.
+
+POSIX letter-colon names such as `a:b` remain valid logical
 names; Windows extraction refuses names its filesystem cannot materialize.

 Extraction materializes regular files exposed by the active archive reader.
@@ -1180,11 +1365,22 @@ failures for such entries name this cause and the operation to rerun with
 Advertised input and output schemas contain no reachable recursive references.
 Input schemas inline repeated definitions before applying the selected
 presentation profile. Both `full` and `compact` start from this self-contained
-projection; output schemas can share schema-local definitions. Full inputs
-retain nested fields, descriptions and valid literal examples. The compatibility
+projection; output schemas can share schema-local definitions. Analyst-authored
+full inputs retain nested fields, descriptions and valid literal examples. The compatibility
 projections below can relax advertised constraints; canonical runtime validation
 still enforces the complete input contract.

+`compare_web_captures` declares its complete producer observations as object
+operands instead of repeating their full output schemas in the input catalog.
+Pass the original `inspect_web_page` normalized result in `before.inspection`
+and `after.inspection`, optional complete `discover_webmcp_tools` results in
+`webmcp`, or complete `capture_browser_scenario` results in the scenario fields.
+Do not construct partial observations from the abbreviated declaration: the
+server still validates every canonical field before comparison. Input groups
+and analyst-authored normalization rules remain explicit. This presentation
+changes no capture bytes, identity, completeness, or comparison semantics and
+does not reduce `inspect_analysis_view` selectors or other tools' declarations.
+
 When a host forwards input schemas to the model, their examples consume context.
 REA's advertised examples therefore never copy complete producer Evidence.
 An embedded Evidence record is shown as its exact `{"kind":"retained-evidence","evidence_id":"ev_..."}`
@@ -1269,6 +1465,16 @@ This addresses the emitted shape reported through a Gemini-backed gateway in
 [#5201](https://github.com/morluto/rea/issues/5201). Gateway conversion and
 live provider acceptance have not been verified for this projection.

+Gemini function declarations accept `items` only beside the single `array`
+type. Reduced array properties therefore advertise the element types their
+canonical item schemas accept, such as `{"type": "object"}` for a union of
+object actions, instead of an any-value type list with nested `items`. An
+element whose type is unknown, a tuple, or an array alongside other types uses
+the empty item schema, and a property that may be an array or another type
+lists typed `anyOf` branches. A boundary test rejects any compact
+advertisement that places `items` beside another type or uses an untyped item
+union.
+
 The compact profile renders the same tool set, output schemas, annotations,
 and canonical server-side validation. It changes only the advertised input
 JSON Schema:
@@ -1306,6 +1512,77 @@ check full-profile local-path rules. Compact MCP workflow tests verify canonical
 rejection of invalid inputs before provider work, independent of how much detail
 the selected advertisement retains.

+### Tool family advertising scope
+
+Agents pay context for every advertised tool schema, and clients that send
+catalog payloads with each request (see the Claude Code measurements above)
+can spend more context on tool definitions than on the investigation. Setting
+the server's `REA_MCP_TOOL_FAMILIES` environment variable to a comma-separated
+subset of the catalog's tool-family ids (the `tools.families` entries in the
+product catalog) restricts the registration to those families. A selection
+outside the published family ids fails server startup with the complete id
+list; the setting is read at startup, so restart the server to apply changes.
+
+Out-of-scope tools stay registered but disabled: `tools/list` omits their
+names and schemas entirely, and a direct call fails with the SDK's
+`Tool ... disabled` invalid-params error rather than disappearing silently.
+`binary_session.tool_availability` and the provider `capabilities` sets on the
+same report, including `analysis_provider_candidates`, list only operations
+whose tools the registration advertises; an operation omitted from those
+projections because of the scope is not callable through this registration,
+and `tools/list` remains the canonical catalog. Availability is derived from
+the complete provider facts before those sets are narrowed, so hiding a direct
+tool does not report an advertised composed tool as unavailable. Guided
+prompts follow the scope too: a workflow is advertised only when every tool in
+its suggested steps belongs to a selected family, so a partially available
+workflow is omitted from `prompts/list` instead of rendering a disabled call;
+`prompts/get` reports it as not found. A scope can omit all guided prompts;
+doctor treats a server without the prompts capability as an empty inventory.
+Recovery instructions recommend runtime settings tools only when `application`
+is advertised; otherwise they explain launch settings and how to widen the scope.
+The server identity digest and
+`rea mcp doctor` tool and prompt inventory derive from the
+same selected scope, so a scoped server reports itself healthy; a scope
+without the `session` family cannot serve `binary_session`, and doctor says
+so explicitly instead of reporting a mismatch. Canonical server-side
+validation and Evidence semantics are unchanged for
+the tools that remain advertised. The default (unset) advertises the complete
+catalog exactly as before. Saved registrations with an invalid selection
+report `invalid` in status instead of starting a server that fails.
+
+`rea setup --client <id> --tool-families <ids>` writes the same selection
+into the `env` object of that client's `rea` entry, so the scope travels with
+the registration; rerunning setup with a different selection refreshes it.
+
+#### Choosing families for common workflows
+
+Every investigation that opens a local binary still needs the `session`
+family: it owns `open_binary`, `binary_session`, the evidence-bundle and
+comparison tools, and the unknown ledger, so include it whenever the workflow
+touches a binary. The `tools.families` entries in the product catalog list
+each family's current inventory; the groupings below describe what a scope
+covers, not a frozen tool count.
+
+Include `application` when a workflow pages retained summaries through
+`inspect_analysis_view` or changes analysis settings. `session` owns Evidence
+bundle import/export; it does not include those view and settings tools.
+
+| Workflow                                          | Scope                                                     | Coverage                                                                                                                                                     |
+| ------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Firmware extraction and analysis                  | `firmware,session,direct`                                 | extract firmware regions, open the extracted image, inspect it with the proxied disassembly tools                                                            |
+| Web investigation                                 | `browser,pcap,session,javascript-runtime`                 | page, bundle and session inspection, packet captures, JS runtime observation, evidence workflow                                                              |
+| Android application analysis                      | `android,adb,apktool,session`                             | class and method inspection, device bridge, resource decoding; add `frida` for dynamic instrumentation, `jeb` for JEB projects, `flutter` for Flutter builds |
+| Native macOS or iOS binary                        | `native,artifact,session`                                 | Mach-O, signature and property-list inspection plus container extraction                                                                                     |
+| Managed .NET assembly                             | `managed,session`                                         | managed member comparison and reconstruction against the evidence workflow                                                                                   |
+| Electron or browser-hosted JavaScript application | `browser,electron,application,javascript-runtime,session` | runtime targets, live page inspection, bundle and capture tools, feature tracing, JavaScript semantics and reconstruction obligations                        |
+| Evidence bookkeeping only                         | `session`                                                 | open and close binaries, bundles, comparisons, unknown tracking                                                                                              |
+
+Scopes are additive and start narrow: begin with the families the workflow
+names, then add one when a call fails with the SDK's `Tool ... disabled`
+error. The error names the disabled tool; `tools.families` in the product
+catalog maps it back to the family that would re-enable it, and the server
+restarts with the wider scope through the same setup flag.
+
 ### Output schemas

 Self-contained output schemas advertise a content-bound `$id`, including their
@@ -1315,21 +1592,39 @@ identity. Explicit schema IDs and relative external reference bases are
 preserved. This keeps every tool and validation rule in discovery and does not
 change the SDK's catalog invalidation or availability checks.

-The server identity's tool-schema digest includes both the canonical output
-contracts and the selected output-schema profile. `full` and `off` therefore
-have distinct identities even though `off` keeps the same canonical output
-validation on the server.
+The server identity's tool-schema digest includes the selected output-schema
+profile and the advertised form that profile produces. `full`, `compact`, and
+`off` therefore have distinct identities. The `compact` digest covers the
+bounded schemas clients receive; `off` keeps the canonical output contracts in
+the digest while advertising nothing.

 Some stdio hosts reject a complete `tools/list` frame before they load any
-tools. The opt-in `REA_MCP_OUTPUT_SCHEMA_PROFILE=off` setting omits `outputSchema`
-from the advertised catalog for hosts with a small frame limit (the measured
-pi-web-ui failure and catalog breakdown are in [#2512](https://github.com/morluto/rea/issues/2512)).
-The default `full` profile is unchanged. With `off`, REA validates successful
-structured results against the same named canonical tool contract before
-delivery; it still returns complete `structuredContent` and text results.
-Only client-side schema discovery and validation are omitted, so hosts using
-this profile should rely on REA's validation and retain their usual response
-size limits.
+tools. The opt-in `REA_MCP_OUTPUT_SCHEMA_PROFILE=compact` setting bounds every
+advertised output schema to 4,096 bytes; `off` omits `outputSchema` entirely
+(the measured pi-web-ui failure and catalog breakdown are in
+[#2512](https://github.com/morluto/rea/issues/2512)). The default `full` profile
+is unchanged. Both settings keep the same named canonical tool contract for
+server-side result validation, and both still return complete
+`structuredContent` and text results.
+
+`compact` keeps the complete validation structure when it fits the budget.
+Otherwise it advertises the root property shape, first-level reference-resolved
+types, first-level guidance, and the root's `required`/`additionalProperties`
+constraints, with nested validation detail elided. Local references are inlined
+within the budget, so the advertised form is self-contained and omits the
+canonical contract's content-bound `$id`. The projection only widens: a valid
+canonical result still satisfies the advertised schema, but a client validating
+against it can accept a result the canonical contract rejects. REA still
+validates every result before delivery. On catalogs large enough that full
+input schemas alone approach the frame limit, keep the input profile at its
+`compact` default as well; with full input schemas the advertisement is
+dominated by the input side.
+The full input profile has no one-megabyte catalog-frame guarantee, including
+when output schemas are omitted.
+
+Only client-side schema discovery and validation are reduced or omitted, so
+hosts using these profiles should rely on REA's validation and retain their
+usual response size limits.

 ### Function comparison limitations

@@ -4,6 +4,40 @@ REA exposes six provider-neutral investigation workflows through the MCP
 `prompts` capability. They complement the generated tool catalog; they do not add, remove, or
 invoke tools by themselves.

+Clients that expose tools but not prompts can use the target-free
+`guided_workflows` tool with `action: "list"` or `action: "render"`. CLI callers
+can use `rea guided-workflows` to list workflows, or pass `--action render`,
+`--workflow-id ID`, and `--arguments-json '{"feature":"offline search"}'` to
+render one. Both paths use the same contracts and renderer as native prompts;
+rendering returns guidance only and does not inspect a target, start analysis,
+or change session state.
+
+The list contains workflow identifiers, descriptions, and argument requirements;
+render returns only the selected workflow's text. Unknown argument names and
+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                                                                              |
@@ -15,6 +49,13 @@ invoke tools by themselves.
 | `audit_residual_unknowns`         | Audit current residual-unknown heads and evidence-qualified resolution.              |
 | `prepare_bounded_process_capture` | Design a bounded controlled process experiment before execution.                     |

+A `REA_MCP_TOOL_FAMILIES` scope advertises a workflow only when every tool in
+its suggested steps belongs to a selected family. Partially available
+workflows are omitted from `prompts/list` — `prompts/get` reports them as not
+found — so a rendered prompt never directs the agent to a disabled call. The
+server identity digest and `rea mcp doctor` prompt inventory follow the same
+scope.
+
 Every rendered prompt provides optional starting points using current REA tool
 names. Agents can call tools directly, skip irrelevant suggestions, and inspect
 provider or target state only when it helps answer the request or a tool
@@ -30,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
@@ -117,12 +117,37 @@ in the JSON for all groups inline. Import the bundle into MCP for views, or
 extract its matching Evidence record to a JSON file for the existing CLI
 `inspect-analysis-view` `evidence-file` source. Input bundles are unchanged.

-Representation admission is bounded at 96 MiB before cloning selected observations
-and expanding matching indexes and repeated per-function source links. Work yields to cancellation. No worker/provider
-concurrency is introduced; this budget is not a bound on total process RSS.
+Representation admission is bounded before cloning selected observations
+and expanding matching indexes and repeated per-function source links. Each
+inventory row is charged before parsing for the member it becomes, including the
+report and Evidence copies that member is serialized into, so an oversized side
+is refused before its rows are parsed. Inline Evidence and bundle records are
+charged for the copies their authentication or loading creates. An exact
+session reference to retained Evidence is borrowed without a copy, so only
+what matching derives from it is charged; the inventory's own Evidence ID is
+charged once, not per function. Selected observations are charged in full.
+Measured under the 96 MiB default with Ghidra-shaped rows, about 20-character
+names and no observations, about 22,000 rows per side fit through retained
+`list_procedures` references, and about 10,000 through inline Evidence or CLI
+`source_bundle` inputs. Work yields to
+cancellation. No worker/provider concurrency is introduced; this budget is not
+a bound on total process RSS.
+
+The allowance defaults to 96 MiB and is the runtime setting
+`native.matching_representation_bytes`, from 1 byte to 1 GiB. On MCP, call
+`update_analysis_settings` with that setting and retry; it applies to the next
+operation without restarting REA. For CLI or future REA processes, set
+`REA_NATIVE_MATCHING_REPRESENTATION_BYTES` in the launch environment; `rea
+setup` copies it into client registrations. An invalid launch value is refused
+by matching only, and a runtime value repairs it. A refusal carries
+`details.limit` with the effective value, its source and bounds. Raising the
+allowance lets matching retain more in the REA process. The 1 GiB maximum is
+an REA policy, not a host-capacity claim, and peak heap during a request can
+exceed the allowance.
+
 Summary delivery happens after complete matching Evidence is constructed and
 retained. It reduces the initial reply, but does not avoid that construction or
-raise the allowance. There is no runtime override. Repeated provenance remains
+raise the allowance. Repeated provenance remains
 part of the complete member contract; splitting inventories into separate matches
 would change global name/body uniqueness and is not an equivalent workaround.

@@ -14,6 +14,10 @@ device platform. A chained-import row ending in `+0x...` is ambiguous in
 dyld's text output: it may be an addend or part of a literal symbol name. REA
 keeps the full expression in `raw_name`, sets `name` and `addend` to null, and
 marks `name_status: "ambiguous"`; it does not synthesize a symbol identity.
+Each import and export `name` is the exact symbol-table spelling, such as
+`_main`; `runtime_name` is the derived name LLDB and `dlsym` use, such as `main`,
+and is null when `name` is null. See [native call observation](#native-call-observation) for
+breakpoint names.

 ## Start with a function

@@ -123,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`
@@ -134,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
@@ -328,10 +336,34 @@ back. The effective heap stays unestablished when either flag is present,
 including when an absolute `--max-old-space-size` is also on the command
 line or in the recovered `NODE_OPTIONS`. Node accepts the config path as
 `=` or the next argument.
-Literal mode retains Unicode casefold matching.
+Literal mode retains Python Unicode full case folding, which can expand a
+character into a sequence: for example, `ss` matches `ß`. This differs from
+REA's Unicode simple case folding used by other native search providers and
+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
@@ -480,8 +512,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
@@ -526,7 +560,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,
@@ -534,15 +582,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.
@@ -579,6 +661,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.
@@ -637,11 +722,10 @@ complete observation.
  outcome instead of rounded reference identities.
  UID 0 cannot distinguish conditional nil from ordinary nil. Limits are
  64 MiB of input, 200,000 objects/references and 128 nesting levels.
-  XML dictionary entries decoded as `__proto__` are omitted with an explicit
-  count because REA results cannot represent that key. XML tag whitespace and
-  comments do not change that handling. XML key names combine their text and
-  CDATA segments without trimming or expanding literal CDATA entities. Other
-  values and the original archive digest are preserved.
+  XML, OpenStep and binary dictionary entries retain their source keys,
+  including `__proto__`, through archive projection and CLI/MCP results.
+  XML key names combine their text and CDATA segments without trimming or
+  expanding literal CDATA entities. The original archive digest is preserved.
  Symbol fallback accepts complete Objective-C class/metaclass symbol leaves,
  including qualified names. Pointer/string labels that merely contain a class
  marker do not establish classes. Provider namespace method labels are not
@@ -697,10 +781,16 @@ complete observation.
  release their representation reservation for later documents.
  Repeated NIBArchive fields retain all serialized values in order. Array
  outlet connections resolve each serialized member and retain the collection
-  object ID and member position on the outlet observation. AppKit object-parent
-  registries use paired keys and parents; objects paired with `NSRoot` are
-  top-level, while nested objects keep their recorded parent. Conflicting or
-  unreadable registry pairs remain incomplete hierarchy evidence.
+  object ID and member position on the outlet observation. NIB hierarchy uses
+  recognized child fields, reverse `NSSuperview` links and window content links.
+  AppKit registry pairs with a resolvable `NSRoot` owner establish top-level
+  membership; other registry associations alone do not establish visual
+  parentage and leave hierarchy coverage partial. Known non-view cell ownership
+  and control-view backreferences remain raw facts. Conflicting explicit parents
+  remain unknown rather than choosing an archive-order winner. Retained objects
+  keep their decoded fields; uncertain registry diagnostics retain the source
+  registry, child and value IDs. Missing, malformed or repeated registry
+  declarations also qualify hierarchy coverage.
  `NSString` objects with the [recognized `NS.bytes` representation](https://github.com/swiftlang/swift-corelibs-foundation/blob/main/Sources/Foundation/NSString.swift#L201-L215) are decoded
  as UTF-8 without substituting malformed bytes. A failed conversion retains
  the source string object ID and `nibValues.NS.bytes` base64 data; dependent
@@ -727,6 +817,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
@@ -821,7 +916,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
@@ -916,15 +1015,22 @@ missing LLDB. `duration_ms` controls the later target observation window.
 rea observe-native-calls /Applications/Example.app '{"breakpoints":[{"kind":"objc-method","class_name":"NSURLSession","selector":"dataTaskWithRequest:completionHandler:"},{"kind":"function","name":"open","module":"libsystem_kernel.dylib"}],"duration_ms":5000,"backtrace_frames":4}' --json
 ```

-Function names select LLDB runtime symbols. On Darwin, a C function reported as
-`_main` by `inspect_macho` or `nm` can resolve as `main` in LLDB. REA preserves the
-exact selected name; it does not remove underscores or translate static names.
-Use `{"kind":"function","name":"main","module":"Example"}` to limit that
-runtime symbol to the executable image named `Example`, then inspect the reported
-locations and image paths. Omitting `module` deliberately matches every loaded
-image, including system libraries. A match outside the executable is valid for
-that request and does not by itself make coverage partial. This C naming example
-does not establish a translation rule for Swift, C++ or other mangled symbols.
+Function names select LLDB runtime symbols. On Darwin, the Mach-O symbol table
+spells language-level symbols with one leading underscore, which LLDB and `dlsym`
+omit: `_main` is `main`, C++ `__ZN3rea3addEii` is `_ZN3rea3addEii`, and Swift
+`_$s…` is `$s…`. Names without that underscore, such as `-[Class selector]`, are
+unchanged. `inspect_macho` keeps each export and import `name` exactly as the
+symbol table spells it and derives its `runtime_name`; pass `runtime_name` as the
+breakpoint `name`. `observe_native_calls` preserves the exact selected name; it
+does not remove underscores or translate static names, so `_main` selects a
+different runtime symbol. Use `{"kind":"function","name":"main","module":"Example"}`
+to limit that runtime symbol to the executable image named `Example`, then inspect
+the reported locations and image paths. Omitting `module` deliberately matches
+every loaded image, including system libraries. A match outside the executable is
+valid for that request and does not by itself make coverage partial. Event and
+location `symbol` values are LLDB display names, which are demangled for C++ and
+Swift; join them to `inspect_macho` through `breakpoint_index` and the request
+`name`, or through `file_address` and the export `address`.

 Each event is an observation: thread, image, symbol, load and file address,
 the raw integer argument registers, optional caller frames and, for an
@@ -995,7 +1101,7 @@ is present. A denied trace reports the `debugger-attach-denied` reason.

 ## Provider and verification boundaries

-Install a Ghidra 12.1.x release and the 64-bit full JDK it declares, then configure REA to
+Install a Ghidra 12.x (>=12.1) release and the 64-bit full JDK it declares, then configure REA to
 use them. Ghidra analysis supports Linux x64/arm64 and macOS x64/arm64; each installation requires
 the matching native decompiler. Experimental Windows x64 P0 admits native
 x86, x86-64, ARMNT (Thumb-2) and ARM64 PE applications and DLLs, plus explicitly selected
@@ -1058,8 +1164,17 @@ counted as known archive omissions. Recognized symlinked `.nib` entries are
 not followed; they retain their paths and reader limitations as counted archive
 omissions. Either gap makes `archive_decode` partial and the graph truncated
 while preserving decoded documents. Its `examined` count remains actual decode
-attempts, and asset-catalog UI joins retain their existing incomplete-graph
-qualification.
+attempts. `archive_object_decode` separately reports whether archive selection
+and decoding examined the object sources; hierarchy-only and connection-only
+unknowns do not make that facet partial. Asset-catalog resource-key joins use
+this source coverage together with document and object projection coverage.
+Incomplete hierarchy or synthetic hierarchy-node limits alone do not qualify
+otherwise complete resource-key joins; omitted archives or resource objects do.
+Archive omission reasons are counted independently of the bounded path samples.
+A UID outside the exact supported range reports `unsupported_uid_exact_range`,
+not budget exhaustion. Mixed source failures report `multiple_archive_decode_causes`;
+limitations retain omission counts by cause even when individual paths exceed
+the reporting allowance.

 UI dispatch joins use the authored receiver's class independently of its
 presentation kind (controller, view, control or another object). An unresolved
@@ -53,6 +53,14 @@ An unset fuse with a present blob is reported as a limitation. These are static
 sentinel observations, not proof of runtime activation: sentinel-like text in
 script or asset bytes also participates in the scan.

+Artifact comparison uses each member's runtime role and exact source key as
+semantic metadata. Unicode-normalized graph paths do not erase differences in
+runtime asset keys. For members paired at the same logical path, a directory
+index change alone does not change the member. Ordinal-based fallback paths can
+change when entries are reordered. When only one observation records member
+metadata, the complete runtime member declaration remains unavailable. Original
+source fields remain available in the retained Evidence.
+
 ## Supported layout and limits

 The decoder follows the 64-bit little-endian layout in Node
@@ -81,9 +81,13 @@ Its separate inferred truncation lengths do not replace that limit; an unset
 file-header limit remains `null`.

 Addresses count once per packet, including loopback and nested IP occurrences.
-DNS addresses are associated only with one question in the same response packet;
-additional records may be included, so this does not prove final resolution.
-Ambiguous addresses remain in a separate inventory. Protocol distribution counts
+DNS address attribution requires one question in one response and complete,
+consistent RR owner/type and section counts. Only answer-section A/AAAA records
+matching that question (or its unambiguous answer-section CNAME chain) are
+associated, with the requested address type respected. Authority, additional,
+unrelated, malformed, and ambiguous addresses remain in the unattributed
+inventory and make coverage partial. These packet-local relationships do not
+prove final resolution or destination authenticity. Protocol distribution counts
 exact nonempty `frame.protocols` stack strings. Frames for which TShark reports
 an empty stack, including zero-length packets, still contribute to the packet
 count without adding a protocol row. An all-empty stack inventory can have
@@ -102,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
@@ -224,11 +224,42 @@ child output. Child output remains in the capture Evidence on stdout.
 resource limits, and normalization settings have defaults; see
 `processScenarioSchema` for the exact contract. Event times are milliseconds
 from launch, must be ordered, and must fall within `timeout_ms`. Inputs marked
-`sensitive` are sent to the process but persisted as a byte-count placeholder.
+`sensitive` are sent to the process but persisted with empty `data`,
+`sensitive: true`, and `input_bytes`. Exact nonempty CR/LF-separated input
+literals are removed from retained terminal text, including cross-chunk and
+VT-styled echoes. Rendering uses that redacted stream, so intermediate terminal
+states and serialized state cannot restore removed bytes. Normalized text is
+checked again. Encoded, transformed, or arbitrarily edited values are not a
+secret-detection contract; their privacy remains unknown. Unmarked inputs and
+caller-selected environment values remain evidence.
+
+The capture-local matcher admits at most 65,536 prefix states and 8,388,608
+construction work units. Projection uses at most 32 MiB of reusable position
+indexes and 67,108,864 work units across one capture. Capacity failures return a
+non-retryable resource error and withhold terminal text in partial observations.
+If output admission leaves gaps, the sensitive capture withholds retained
+terminal text rather than interpreting separated fragments as a complete stream.
+`raw_terminal.redacted_bytes` reports bytes removed from admitted original
+chunks; these bytes still consume `output_bytes` alongside retained safe bytes.
+Private display effects remain unknown, with frame order and provenance retained.
+
+This changes the sensitive-input Evidence representation: consumers of the old
+`<redacted-input:N-bytes>` placeholder must read `input_bytes` instead. Existing
+saved captures remain readable and are not rewritten; old files may still
+contain previously echoed input. A private-input comparison policy version
+separates old and new captures; reacquire both sides for comparable observations.
 Environment overrides are recorded in the scenario commitment; inherited
 values are not copied into Evidence.

-Terminal dimensions must satisfy `columns × (rows + scrollback) ≤ 1,000,000`.
+A bare executable name uses the scenario's `PATH` override, then the inherited
+`PATH`. When neither supplies `PATH`, lookup uses `/usr/bin:/bin`, matching
+[Node's Unix default](https://nodejs.org/api/child_process.html#child-process).
+An explicitly empty `PATH` searches only the working directory. Executable,
+working-directory, and observation paths preserve native `symlink/..` traversal.
+
+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
@@ -288,7 +319,8 @@ own classification until its exact resources are released.

 Terminal frame `data` is the comparison text after the selected normalization.
 New captures also preserve `raw_data` when normalization changes a PTY chunk;
-otherwise `data` is already the original text. Older captures may lack the
+otherwise `data` is already that text. For sensitive captures, both fields
+contain only the safe projection; no unredacted backup is retained. Older captures may lack the
 original text for changed chunks. Both values participate in Evidence identity,
 while comparisons and trace assertions use the normalized text. Retaining the
 original adds at most `limits.output_bytes` of text, because it comes from the
@@ -323,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
@@ -494,6 +529,11 @@ Every capture requires `truncation_details`, with separate accounting for:
  An unreadable directory is recorded in `enumeration_omissions` with its
  root-aliased path and operating-system error code. Entries observed before
  that directory remain available, while descendants beneath it stay unknown.
+  A basename that is not valid UTF-8 is never looked up through replacement
+  characters. It consumes entry capacity and records an `unrepresentable_name`
+  omission at its containing directory, with exact basename bytes in
+  `raw_name_hex` and a null `system_code`. That root's enumeration remains
+  incomplete, so missing paths beneath it remain unknown.
  Each retained regular file without a digest has an aliased path, size,
  remaining budget and reason: `file_bytes_budget`,
  `file_changed_or_short_read`, or `file_unavailable`. Its `system_code` is
@@ -657,3 +697,11 @@ REA then preserves ownership uncertainty and can report `cleanup_incomplete`;
 it does not disable verification to continue. A sandbox that explicitly allows
 this read-only process inspector is a separate prerequisite from the compiler
 and cache settings.
+
+Symlink observations preserve their stored target bytes in `symlink_target_hex`
+(lowercase hexadecimal). `symlink_target` retains valid UTF-8 text and is `null`
+when the target bytes cannot be decoded as UTF-8. Filesystem effects compare
+these exact bytes without resolving the link. Older captures without the hex
+field still parse; a legacy target containing U+FFFD has ambiguous byte identity,
+so matching target text alone produces an `unknown` effect. Symlink descendants
+remain outside filesystem observation regardless of target encoding.
@@ -20,7 +20,7 @@

 **[الموقع](https://rea.tools/ar/) · [الأدلة](https://rea.tools/ar/guides/) · [دراسات الحالة](https://rea.tools/ar/showcase/)**

-[البدء السريع](#البدء-السريع) · [كيف يعمل REA](#كيف-يعمل-rea) · [ما الذي يمكنك تحليله](#ما-الذي-يمكنك-تحليله) · [دراسات الحالة](#دراسات-الحالة) · [الأسئلة الشائعة](#الأسئلة-الشائعة) · [أدوات GNU objdump وRizin](../reverse-engineering-tools.md) · [التوثيق](#التوثيق)
+[البدء السريع](#البدء-السريع) · [كيف يعمل REA](#كيف-يعمل-rea) · [ما الذي يمكنك تحليله](#ما-الذي-يمكنك-تحليله) · [دراسات الحالة](#دراسات-الحالة) · [إنشاء بيئات التعلم المعزز](#build-rl-environments) · [الأسئلة الشائعة](#الأسئلة-الشائعة) · [أدوات GNU objdump وRizin](../reverse-engineering-tools.md) · [التوثيق](#التوثيق)

 <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/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)                                                                        |
@@ -225,8 +225,51 @@ npx rea-agents@latest setup
 [اقرأ دراسة الحالة](https://rea.tools/ar/showcase/th04/) ·
 [مستودع إعادة البناء](https://github.com/N0zoM1z0/th04)

+### إنشاء بيئات التعلم المعزز باستخدام REA
+
+سجّل جلسة لتطبيق ويب، وحوّل API إلى أدوات، وصدّر بيئة يستطيع وكيل الذكاء الاصطناعي استخدامها. شغّلها باستخدام AgentEnv، ثم أضف المهام وفحوص المكافآت للتدريب بالتعلم المعزز أو التقييم.
+
+[دليل إنشاء بيئة](https://rea.tools/guides/rl-environments/) ·
+[شاهد العرض على X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 إذا استخدمت REA لفحص هدف مثير للاهتمام، فنود الاطلاع عليه. شارك حالتك في [issue](https://github.com/morluto/rea/issues) أو [pull request](https://github.com/morluto/rea/pulls)، مع ذكر الهدف، وسؤالك، وكيف ساعدك REA، وما توصلت إليه.

+<a id="build-rl-environments"></a>
+
+## إنشاء بيئات التعلم المعزز
+
+أنشئ بيئة محلية يتدرب فيها وكيل الذكاء الاصطناعي على مهام مثل البحث عن مشكلة أو إنشاء مجلد، دون تشغيل التطبيق الأصلي. استخدمها للتعلم المعزز (RL) أو لاختبار قدرة الوكيل على إنجاز المهام.
+
+يحوّل REA طلبات API والردود المسجلة إلى أدوات يمكن للوكيل استدعاؤها. تستخدم البيئة البيانات المسجلة ولا تدعم التغييرات إلا عندما يؤكد التسجيل آثارها.
+
+بعد إعداد REA في وكيلك، استبدل رابط المثال ومهام المجلدات بما يناسب تطبيقك:
+
+```text
+استخدم REA لإنشاء بيئة تعلم معزز من تطبيق الويب الاختباري لدي على
+http://127.0.0.1:3000
+غطّ عرض المجلدات وإنشاءها وإعادة تسميتها وحذفها. يمكنك إنشاء مجلدات اختبار
+وحذفها، لكن لا تغيّر البيانات الموجودة.
+احفظ البيئة في مجلد باسم my-env، وتحقق من العمليات المتاحة وأخبرني كيف أشغّلها.
+```
+
+<details>
+<summary>استخدام سطر الأوامر</summary>
+
+استخدم هذه الأوامر إذا كان لديك ملف يسجل طلبات التطبيق وردوده في المتصفح. يتطلب تشغيل النتيجة أيضًا AgentEnv وDocker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+يصدّر REA بيئة قابلة للتشغيل مع اختبار أساسي يتحقق من بدء تشغيلها واستجابتها. استخدمها مع إطار التعلم المعزز لتحديد أهداف المهام وإضافة فحوص المكافآت وتشغيل التدريب.
+
+[دليل إنشاء بيئة](https://rea.tools/guides/rl-environments/) ·
+[مرجع البيئات](../agent-environments.md) ·
+[شاهد العرض على X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## الأسئلة الشائعة

 <details>
@@ -237,9 +280,9 @@ npx rea-agents@latest setup
 </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>

@@ -307,7 +350,7 @@ npx rea-agents@latest setup

 ## سجل النجوم

-🎉 **300,000 نجمة على GitHub — شكرًا لكم!**
+🎉 **400,000 نجمة على GitHub — شكرًا لكم!**

 شكرًا لكل من يستخدم REA، ويبلّغ عن الأخطاء، ويقترح ميزات، ويختبر إصدارات البناء، ويساهم بالإصلاحات.

@@ -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) · [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.
@@ -223,8 +225,51 @@ Untersuche die 16-Bit-Anweisungen des ursprünglichen PC-98-Spiels, rekonstruier

 [Fallstudie lesen](https://rea.tools/de/showcase/th04/) · [Rekonstruktionsrepository](https://github.com/N0zoM1z0/th04)

+### RL-Umgebungen mit REA erstellen
+
+Zeichne eine Webanwendungssitzung auf, verwandle ihre API in Werkzeuge und exportiere eine Umgebung für einen KI-Agenten. Starte sie mit AgentEnv und ergänze Aufgaben und Belohnungsprüfungen für RL-Training oder Bewertung.
+
+[Anleitung zum Erstellen einer Umgebung](https://rea.tools/guides/rl-environments/) ·
+[Demo auf X ansehen](https://x.com/reatools/status/2112574822584918075?s=20)
+
 Wenn du mit REA etwas Interessantes untersucht hast, würden wir es gern sehen. Teile deine Fallstudie in einem [Issue](https://github.com/morluto/rea/issues) oder [Pull Request](https://github.com/morluto/rea/pulls) und beschreibe das Ziel, deine Frage, wie REA geholfen hat und was du herausgefunden hast.

+<a id="build-rl-environments"></a>
+
+## RL-Umgebungen erstellen
+
+Erstelle eine lokale Umgebung, in der ein KI-Agent Aufgaben wie das Finden eines Issues oder das Anlegen eines Ordners üben kann, ohne die ursprüngliche App auszuführen. Nutze sie für Reinforcement Learning (RL) oder um zu testen, wie gut ein Agent Aufgaben erledigt.
+
+REA wandelt aufgezeichnete API-Anfragen und Antworten in Werkzeuge um, die der Agent aufrufen kann. Die Umgebung nutzt die aufgezeichneten Daten und unterstützt Änderungen nur, wenn die Aufzeichnung deren Wirkung bestätigt.
+
+Richte REA in deinem Agenten ein und ersetze die Beispiel-URL und die Ordneraufgaben durch deine eigenen:
+
+```text
+Erstelle mit REA eine RL-Umgebung aus meiner Test-Web-App unter
+http://127.0.0.1:3000.
+Decke das Auflisten, Erstellen, Umbenennen und Löschen von Ordnern ab.
+Du darfst Testordner anlegen und entfernen. Lass bestehende Daten unverändert.
+Speichere sie in einem Ordner namens my-env, prüfe die verfügbaren Operationen und erkläre mir den Start.
+```
+
+<details>
+<summary>Stattdessen die Befehlszeile verwenden</summary>
+
+Nutze diese Befehle, wenn du bereits eine Datei mit aufgezeichneten Browseranfragen und Antworten der App hast. Zum Ausführen des Ergebnisses brauchst du außerdem AgentEnv und Docker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA exportiert eine lauffähige Umgebung mit einem einfachen Test, der prüft, ob sie startet und antwortet. Nutze sie mit deinem RL-Framework, um Aufgabenziele und Belohnungsprüfungen festzulegen und das Training auszuführen.
+
+[Anleitung zum Erstellen einer Umgebung](https://rea.tools/guides/rl-environments/) ·
+[Umgebungsreferenz](../agent-environments.md) ·
+[Demo auf X ansehen](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## Häufige Fragen

 <details>
@@ -235,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>

@@ -305,7 +350,7 @@ Melde Sicherheitslücken gemäß [SECURITY.md](../../SECURITY.md).

 ## Sternverlauf

-🎉 **300.000 GitHub-Sterne – vielen Dank!**
+🎉 **400.000 GitHub-Sterne – vielen Dank!**

 Danke an alle, die REA nutzen, Fehler melden, Funktionswünsche äußern, Builds testen und Fehlerbehebungen beitragen.

@@ -19,7 +19,7 @@

 **[Ιστότοπος](https://rea.tools/) · [Οδηγοί](https://rea.tools/guides/) · [Μελέτες περίπτωσης](https://rea.tools/showcase/)**

-[Γρήγορη εκκίνηση](#γρήγορη-εκκίνηση) · [Πώς λειτουργεί το REA](#πώς-λειτουργεί-το-rea) · [Τι μπορείς να αναλύσεις](#τι-μπορείς-να-αναλύσεις) · [Μελέτες περίπτωσης](#μελέτες-περίπτωσης) · [Συχνές ερωτήσεις](#συχνές-ερωτήσεις) · [Τεκμηρίωση](#τεκμηρίωση)
+[Γρήγορη εκκίνηση](#γρήγορη-εκκίνηση) · [Πώς λειτουργεί το REA](#πώς-λειτουργεί-το-rea) · [Τι μπορείς να αναλύσεις](#τι-μπορείς-να-αναλύσεις) · [Μελέτες περίπτωσης](#μελέτες-περίπτωσης) · [Δημιουργία περιβαλλόντων RL](#build-rl-environments) · [Συχνές ερωτήσεις](#συχνές-ερωτήσεις) · [Τεκμηρίωση](#τεκμηρίωση)

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

@@ -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)                                         |
@@ -227,8 +227,51 @@ npx rea-agents@latest setup

 [Διάβασε τη μελέτη περίπτωσης](https://rea.tools/showcase/th04/) · [Αποθετήριο ανακατασκευής](https://github.com/N0zoM1z0/th04)

+### Δημιουργία περιβαλλόντων RL με το REA
+
+Καταγράψτε μια συνεδρία εφαρμογής ιστού, μετατρέψτε το API της σε εργαλεία και εξαγάγετε ένα περιβάλλον για πράκτορα AI. Εκτελέστε το με το AgentEnv και προσθέστε εργασίες και ελέγχους ανταμοιβής για εκπαίδευση RL ή αξιολόγηση.
+
+[Οδηγός δημιουργίας περιβάλλοντος](https://rea.tools/guides/rl-environments/) ·
+[Δείτε το demo στο X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 Αν χρησιμοποίησες το REA για κάτι ενδιαφέρον, θα θέλαμε να το δούμε. Μοιράσου τη μελέτη σου σε ένα [issue](https://github.com/morluto/rea/issues) ή [pull request](https://github.com/morluto/rea/pulls), αναφέροντας τον στόχο, το ερώτημά σου, πώς βοήθησε το REA και τι ανακάλυψες.

+<a id="build-rl-environments"></a>
+
+## Δημιουργία περιβαλλόντων RL
+
+Δημιουργήστε ένα τοπικό περιβάλλον όπου ένας πράκτορας AI εξασκείται σε εργασίες όπως η εύρεση ενός issue ή η δημιουργία φακέλου, χωρίς να εκτελείται η αρχική εφαρμογή. Χρησιμοποιήστε το για ενισχυτική μάθηση (RL) ή για να ελέγξετε πόσο καλά ολοκληρώνει εργασίες ο πράκτορας.
+
+Το REA μετατρέπει καταγεγραμμένα αιτήματα και απαντήσεις API σε εργαλεία που μπορεί να καλεί ο πράκτορας. Το περιβάλλον χρησιμοποιεί τα καταγεγραμμένα δεδομένα και υποστηρίζει αλλαγές μόνο όταν η καταγραφή επιβεβαιώνει τα αποτελέσματά τους.
+
+Ρυθμίστε το REA στον πράκτορά σας και προσαρμόστε το URL και τις εργασίες φακέλων του παραδείγματος:
+
+```text
+Χρησιμοποίησε το REA για να δημιουργήσεις περιβάλλον RL από τη δοκιμαστική εφαρμογή μου:
+http://127.0.0.1:3000
+Κάλυψε προβολή, δημιουργία, μετονομασία και διαγραφή φακέλων. Μπορείς να δημιουργείς
+και να αφαιρείς δοκιμαστικούς φακέλους, αλλά μην αλλάξεις τα υπάρχοντα δεδομένα.
+Αποθήκευσέ το σε φάκελο my-env, έλεγξε τις διαθέσιμες λειτουργίες και πες μου πώς εκτελείται.
+```
+
+<details>
+<summary>Χρήση της γραμμής εντολών</summary>
+
+Χρησιμοποιήστε αυτές τις εντολές αν έχετε ήδη αρχείο με τα καταγεγραμμένα αιτήματα και τις απαντήσεις της εφαρμογής στο πρόγραμμα περιήγησης. Η εκτέλεση χρειάζεται επίσης AgentEnv και Docker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+Το REA εξάγει ένα εκτελέσιμο περιβάλλον με μια βασική δοκιμή εκκίνησης και απόκρισης. Συνδέστε το στο πλαίσιο RL για να ορίσετε στόχους, να προσθέσετε ελέγχους ανταμοιβής και να εκτελέσετε εκπαίδευση.
+
+[Οδηγός δημιουργίας περιβάλλοντος](https://rea.tools/guides/rl-environments/) ·
+[Αναφορά περιβαλλόντων](../agent-environments.md) ·
+[Δείτε το demo στο X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## Συχνές ερωτήσεις

 <details>
@@ -239,9 +282,9 @@ npx rea-agents@latest setup
 </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>

@@ -309,7 +352,7 @@ npx rea-agents@latest setup

 ## Ιστορικό αστεριών

-🎉 **300.000 αστέρια στο GitHub — σας ευχαριστούμε!**
+🎉 **400.000 αστέρια στο GitHub — σας ευχαριστούμε!**

 Ευχαριστούμε όλους όσοι χρησιμοποιούν το REA, αναφέρουν σφάλματα, ζητούν νέες λειτουργίες, δοκιμάζουν builds και συνεισφέρουν διορθώσεις.

@@ -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) · [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`.
@@ -223,8 +225,51 @@ Inspecciona las instrucciones de 16 bits del juego original para PC-98, recupera

 [Lee el caso práctico](https://rea.tools/es/showcase/th04/) · [Repositorio de reconstrucción](https://github.com/N0zoM1z0/th04)

+### Crear entornos de RL con REA
+
+Graba una sesión de una aplicación web, convierte su API en herramientas y exporta un entorno que un agente de IA pueda usar. Ejecútalo con AgentEnv y añade tareas y comprobaciones de recompensa para entrenamiento RL o evaluación.
+
+[Guía para crear un entorno](https://rea.tools/guides/rl-environments/) ·
+[Ver la demo en X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 Si has usado REA para investigar algo interesante, nos gustaría verlo. Comparte tu caso en una [issue](https://github.com/morluto/rea/issues) o una [pull request](https://github.com/morluto/rea/pulls), incluyendo el objetivo, tu pregunta, cómo te ayudó REA y qué encontraste.

+<a id="build-rl-environments"></a>
+
+## Crear entornos de RL
+
+Crea un entorno local donde un agente de IA pueda practicar tareas como buscar un issue o crear una carpeta, sin ejecutar la aplicación original. Úsalo para aprendizaje por refuerzo (RL) o para comprobar cómo completa las tareas un agente.
+
+REA convierte las solicitudes y respuestas de API grabadas en herramientas que el agente puede llamar. El entorno usa los datos grabados y solo admite cambios cuyos efectos confirma la grabación.
+
+Configura REA en tu agente y sustituye la URL y las tareas de carpetas del ejemplo por las tuyas:
+
+```text
+Usa REA para crear un entorno de RL a partir de mi aplicación web de prueba en
+http://127.0.0.1:3000.
+Incluye listar, crear, renombrar y borrar carpetas. Puedes crear y borrar
+carpetas de prueba, pero no modifiques los datos existentes.
+Guárdalo en una carpeta llamada my-env, comprueba qué operaciones funcionan y dime cómo ejecutarlo.
+```
+
+<details>
+<summary>Usar la línea de comandos</summary>
+
+Usa estos comandos si ya tienes un archivo con las solicitudes y respuestas de la aplicación grabadas en el navegador. Para ejecutar el resultado también necesitas AgentEnv y Docker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA exporta un entorno ejecutable con una prueba básica que comprueba que arranca y responde. Úsalo con tu framework de RL para definir objetivos, añadir comprobaciones de recompensa y ejecutar el entrenamiento.
+
+[Guía para crear un entorno](https://rea.tools/guides/rl-environments/) ·
+[Referencia de entornos](../agent-environments.md) ·
+[Ver la demo en X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## Preguntas frecuentes

 <details>
@@ -235,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>

@@ -305,7 +350,7 @@ Informa de vulnerabilidades siguiendo [SECURITY.md](../../SECURITY.md).

 ## Historial de estrellas

-🎉 **300.000 estrellas en GitHub: ¡gracias!**
+🎉 **400.000 estrellas en GitHub: ¡gracias!**

 Gracias a quienes usan REA, informan de errores, solicitan funciones, prueban compilaciones y contribuyen con correcciones.

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

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

-[شروع سریع](#شروع-سریع) · [REA چگونه کار می‌کند؟](#rea-چگونه-کار-می‌کند) · [چه چیزهایی را میتوان تحلیل کرد؟](#چه-چیزهایی-را-می‌توان-تحلیل-کرد) · [نمونه‌های عملی](#نمونه‌های-عملی) · [پرسش‌های متداول](#پرسش‌های-متداول) · [ابزارهای 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` افزایش دهید.
@@ -215,8 +217,51 @@ API کلیپ‌بورد در renderer را پیدا کنید، مسیر آن ر

 [مطالعهٔ موردی](https://rea.tools/fa/showcase/th04/) · [مخزن بازسازی](https://github.com/N0zoM1z0/th04)

+### ساخت محیط‌های RL با REA
+
+یک نشست برنامهٔ وب را ضبط کنید، API آن را به ابزار تبدیل کنید و محیطی برای عامل هوش مصنوعی صادر کنید. آن را با AgentEnv اجرا کنید و کارها و بررسی پاداش را برای آموزش RL یا ارزیابی اضافه کنید.
+
+[راهنمای ساخت محیط](https://rea.tools/guides/rl-environments/) ·
+[نمایش را در X ببینید](https://x.com/reatools/status/2112574822584918075?s=20)
+
 اگر از REA برای بررسی موضوع جالبی استفاده کرده‌اید، خوشحال می‌شویم آن را به اشتراک بگذارید. یک [issue](https://github.com/morluto/rea/issues) یا [pull request](https://github.com/morluto/rea/pulls) ثبت کنید و هدف، پرسش خود، نقش REA و یافته‌هایتان را توضیح دهید.

+<a id="build-rl-environments"></a>
+
+## ساخت محیط‌های RL
+
+محیطی محلی بسازید تا عامل هوش مصنوعی بدون اجرای برنامهٔ اصلی، کارهایی مثل پیدا کردن یک مسئله یا ساخت پوشه را تمرین کند. از آن برای یادگیری تقویتی (RL) یا سنجش توانایی عامل در انجام کارها استفاده کنید.
+
+REA درخواست‌ها و پاسخ‌های ضبط‌شدهٔ API را به ابزارهایی تبدیل می‌کند که عامل می‌تواند فراخوانی کند. محیط از داده‌های ضبط‌شده استفاده می‌کند و فقط تغییراتی را پشتیبانی می‌کند که اثرشان در ضبط تأیید شده باشد.
+
+پس از راه‌اندازی REA در عامل، نشانی نمونه و کارهای مربوط به پوشه را با موارد خودتان جایگزین کنید:
+
+```text
+با REA از برنامهٔ وب آزمایشی من در این نشانی یک محیط RL بساز:
+http://127.0.0.1:3000
+فهرست کردن، ساختن، تغییر نام و حذف پوشه‌ها را پوشش بده. می‌توانی پوشه‌های
+آزمایشی بسازی و حذف کنی، اما داده‌های موجود را تغییر نده.
+در پوشه‌ای به نام my-env ذخیره کن، عملیات قابل استفاده را بررسی کن و روش اجرا را بگو.
+```
+
+<details>
+<summary>استفاده از خط فرمان</summary>
+
+اگر فایل ضبط درخواست‌ها و پاسخ‌های برنامه در مرورگر را دارید، از این فرمان‌ها استفاده کنید. اجرای نتیجه به AgentEnv و Docker هم نیاز دارد.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA محیطی آمادهٔ اجرا همراه با یک آزمون ساده برای بررسی شروع به کار و پاسخ‌گویی آن صادر می‌کند. آن را به چارچوب RL متصل کنید تا اهداف کارها و بررسی پاداش را تعریف و آموزش را اجرا کنید.
+
+[راهنمای ساخت محیط](https://rea.tools/guides/rl-environments/) ·
+[مرجع محیط‌ها](../agent-environments.md) ·
+[نمایش را در X ببینید](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## پرسش‌های متداول

 <details><summary><strong>کدام ایجنت‌ها می‌توانند از REA استفاده کنند؟</strong></summary>
@@ -225,9 +270,9 @@ API کلیپ‌بورد در renderer را پیدا کنید، مسیر آن ر

 </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>

@@ -290,7 +335,7 @@ npx rea-agents@latest setup

 ## تاریخچهٔ ستاره‌ها

-🎉 **۳۰۰٬۰۰۰ ستارهٔ GitHub — سپاسگزاریم!**
+🎉 **۴۰۰٬۰۰۰ ستارهٔ GitHub — سپاسگزاریم!**

 از همهٔ کسانی که از REA استفاده می‌کنند، خطاها را گزارش می‌دهند، قابلیت‌های جدید پیشنهاد می‌کنند، buildها را آزمایش می‌کنند و در بهبود پروژه مشارکت دارند سپاسگزاریم.

@@ -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) · [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.
@@ -220,8 +222,51 @@ Inspectez les instructions 16 bits du jeu PC-98 d'origine, retrouvez les calculs

 [Lire l'étude de cas](https://rea.tools/fr/showcase/th04/) · [Dépôt de la reconstruction](https://github.com/N0zoM1z0/th04)

+### Créer des environnements RL avec REA
+
+Enregistrez une session d’application web, transformez son API en outils et exportez un environnement utilisable par un agent IA. Exécutez-le avec AgentEnv, puis ajoutez des tâches et des vérifications de récompense pour l’entraînement RL ou l’évaluation.
+
+[Guide de création d’un environnement](https://rea.tools/guides/rl-environments/) ·
+[Voir la démo sur X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 Si vous avez utilisé REA sur un projet intéressant, nous serions ravis de le découvrir. Partagez votre cas dans une [issue](https://github.com/morluto/rea/issues) ou une [pull request](https://github.com/morluto/rea/pulls), en précisant la cible, votre question, la manière dont REA vous a aidé et ce que vous avez découvert.

+<a id="build-rl-environments"></a>
+
+## Créer des environnements RL
+
+Créez un environnement local où un agent IA peut s’exercer à des tâches comme trouver un ticket ou créer un dossier, sans exécuter l’application d’origine. Utilisez-le pour l’apprentissage par renforcement (RL) ou pour tester la capacité d’un agent à accomplir des tâches.
+
+REA transforme les requêtes et réponses API enregistrées en outils que l’agent peut appeler. L’environnement utilise les données enregistrées et ne prend en charge des modifications que si l’enregistrement confirme leurs effets.
+
+Configurez REA dans votre agent, puis adaptez l’URL et les tâches sur les dossiers à votre application :
+
+```text
+Utilise REA pour créer un environnement RL à partir de mon application web de test à
+http://127.0.0.1:3000.
+Couvre la liste, la création, le renommage et la suppression de dossiers.
+Tu peux créer et supprimer des dossiers de test. Ne modifie pas les données existantes.
+Enregistre-le dans un dossier nommé my-env, vérifie les opérations disponibles et explique-moi comment le lancer.
+```
+
+<details>
+<summary>Utiliser la ligne de commande</summary>
+
+Utilisez ces commandes si vous disposez déjà d’un fichier contenant les requêtes et réponses de l’application enregistrées dans le navigateur. L’exécution du résultat nécessite aussi AgentEnv et Docker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA exporte un environnement exécutable avec un test de base qui vérifie qu’il démarre et répond. Utilisez-le avec votre framework RL pour définir les objectifs, ajouter les vérifications de récompense et lancer l’entraînement.
+
+[Guide de création d’un environnement](https://rea.tools/guides/rl-environments/) ·
+[Référence des environnements](../agent-environments.md) ·
+[Voir la démo sur X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## Questions fréquentes

 <details>
@@ -232,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>

@@ -302,7 +347,7 @@ Signalez les vulnérabilités via [SECURITY.md](../../SECURITY.md).

 ## Historique des étoiles

-🎉 **300 000 étoiles GitHub — merci !**
+🎉 **400 000 étoiles GitHub — merci !**

 Merci à toutes les personnes qui utilisent REA, signalent des bugs, proposent des fonctionnalités, testent les builds et contribuent des correctifs.

@@ -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) · [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).
@@ -231,8 +233,51 @@ Periksa instruksi 16-bit dari gim PC-98 asli, pulihkan perhitungan sudut tetap d

 [Baca studi kasus](https://rea.tools/id/showcase/th04/) · [Repositori rekonstruksi](https://github.com/N0zoM1z0/th04)

+### Bangun lingkungan RL dengan REA
+
+Rekam sesi aplikasi web, ubah API menjadi alat, lalu ekspor lingkungan yang dapat digunakan agen AI. Jalankan dengan AgentEnv dan tambahkan tugas serta pemeriksaan reward untuk pelatihan RL atau evaluasi.
+
+[Panduan membangun lingkungan](https://rea.tools/guides/rl-environments/) ·
+[Tonton demo di X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 Jika Anda telah menggunakan REA untuk menganalisis sesuatu yang menarik, kami ingin melihat hasilnya. Bagikan kasus Anda melalui [issue](https://github.com/morluto/rea/issues) atau [pull request](https://github.com/morluto/rea/pulls), sertakan target, pertanyaan Anda, bagaimana REA membantu, dan apa yang Anda temukan.

+<a id="build-rl-environments"></a>
+
+## Membangun lingkungan RL
+
+Buat lingkungan lokal agar agen AI dapat berlatih tugas seperti mencari issue atau membuat folder tanpa menjalankan aplikasi aslinya. Gunakan untuk pembelajaran penguatan (RL) atau menguji kemampuan agen menyelesaikan tugas.
+
+REA mengubah permintaan dan respons API yang direkam menjadi alat yang dapat dipanggil agen. Lingkungan memakai data rekaman dan hanya mendukung perubahan yang dampaknya dikonfirmasi oleh rekaman.
+
+Setelah menyiapkan REA di agen, ganti URL contoh dan tugas folder di bawah sesuai aplikasi Anda:
+
+```text
+Gunakan REA untuk membuat lingkungan RL dari aplikasi web uji saya di
+http://127.0.0.1:3000.
+Cakup daftar, pembuatan, penggantian nama, dan penghapusan folder. Boleh membuat
+dan menghapus folder uji, tetapi jangan ubah data yang sudah ada.
+Simpan dalam folder bernama my-env, periksa operasi yang berfungsi, dan beri tahu cara menjalankannya.
+```
+
+<details>
+<summary>Gunakan baris perintah</summary>
+
+Gunakan perintah ini jika Anda sudah punya file rekaman permintaan dan respons aplikasi di browser. Untuk menjalankan hasilnya, Anda juga perlu AgentEnv dan Docker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA mengekspor lingkungan yang dapat dijalankan dengan uji dasar untuk memeriksa bahwa lingkungan mulai dan merespons. Hubungkan ke framework RL untuk menetapkan tujuan tugas, menambahkan pemeriksaan reward, dan menjalankan pelatihan.
+
+[Panduan membangun lingkungan](https://rea.tools/guides/rl-environments/) ·
+[Referensi lingkungan](../agent-environments.md) ·
+[Tonton demo di X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## FAQ

 <details>
@@ -243,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>

@@ -323,7 +368,7 @@ Laporkan kerentanan melalui [SECURITY.md](../../SECURITY.md).

 ## Riwayat Bintang

-🎉 **300.000 bintang GitHub, terima kasih!**
+🎉 **400.000 bintang GitHub, terima kasih!**

 Terima kasih kepada semua orang yang menggunakan REA, melaporkan bug, meminta fitur, menguji build, dan berkontribusi dalam perbaikan.

@@ -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) · [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.
@@ -220,8 +222,51 @@ Ispeziona le istruzioni a 16 bit del gioco PC-98 originale, recupera i calcoli d

 [Leggi il case study](https://rea.tools/it/showcase/th04/) · [Repository di ricostruzione](https://github.com/N0zoM1z0/th04)

+### Creare ambienti RL con REA
+
+Registra una sessione di un’app web, trasforma la sua API in strumenti ed esporta un ambiente utilizzabile da un agente IA. Eseguilo con AgentEnv, poi aggiungi attività e controlli sulle ricompense per l’addestramento RL o la valutazione.
+
+[Guida alla creazione di un ambiente](https://rea.tools/guides/rl-environments/) ·
+[Guarda la demo su X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 Se hai usato REA su qualcosa di interessante, ci piacerebbe vederlo. Condividi il tuo caso in una [issue](https://github.com/morluto/rea/issues) o in una [pull request](https://github.com/morluto/rea/pulls), includendo il bersaglio, la tua domanda, come REA ti ha aiutato e cosa hai scoperto.

+<a id="build-rl-environments"></a>
+
+## Creare ambienti RL
+
+Crea un ambiente locale in cui un agente IA possa esercitarsi in attività come cercare una issue o creare una cartella, senza eseguire l’app originale. Usalo per l’apprendimento per rinforzo (RL) o per verificare come l’agente completa le attività.
+
+REA trasforma le richieste e le risposte API registrate in strumenti che l’agente può chiamare. L’ambiente usa i dati registrati e supporta modifiche solo quando la registrazione ne conferma gli effetti.
+
+Configura REA nel tuo agente, poi sostituisci l’URL e le attività sulle cartelle dell’esempio con i tuoi:
+
+```text
+Usa REA per creare un ambiente RL dalla mia app web di prova su
+http://127.0.0.1:3000.
+Includi elenco, creazione, rinomina ed eliminazione delle cartelle. Puoi creare
+e rimuovere cartelle di prova, ma non modificare i dati esistenti.
+Salvalo in una cartella chiamata my-env, verifica le operazioni disponibili e spiegami come eseguirlo.
+```
+
+<details>
+<summary>Usare la riga di comando</summary>
+
+Usa questi comandi se hai già un file con le richieste e le risposte dell’app registrate nel browser. Per eseguire il risultato servono anche AgentEnv e Docker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA esporta un ambiente eseguibile con un test di base che ne verifica l’avvio e le risposte. Usalo con il tuo framework RL per definire gli obiettivi, aggiungere controlli sulle ricompense ed eseguire l’addestramento.
+
+[Guida alla creazione di un ambiente](https://rea.tools/guides/rl-environments/) ·
+[Riferimento degli ambienti](../agent-environments.md) ·
+[Guarda la demo su X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## FAQ

 <details>
@@ -232,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>

@@ -302,7 +347,7 @@ Segnala vulnerabilità tramite [SECURITY.md](../../SECURITY.md).

 ## Cronologia delle stelle

-🎉 **300.000 stelle su GitHub — grazie!**
+🎉 **400.000 stelle su GitHub — grazie!**

 Grazie a tutti coloro che usano REA, segnalano bug, propongono funzionalità, testano le build e contribuiscono con correzioni.

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

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

-[クイックスタート](#クイックスタート) · [REA の仕組み](#rea-の仕組み) · [分析できる対象](#分析できる対象) · [事例](#事例) · [よくある質問](#よくある質問) · [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` でプロバイダーの起動期限を延長できます。
@@ -225,8 +227,51 @@ REA には Node.js 22.x（>=22.23.4）、24.x（>=24.22.1）、または 26+ (>=
 [事例を読む](https://rea.tools/ja/showcase/th04/) ·
 [再構築リポジトリ](https://github.com/N0zoM1z0/th04)

+### REA で RL 環境を構築する
+
+Web アプリのセッションを記録し、API をツールに変換して、AI エージェントが使える環境をエクスポートします。AgentEnv で実行し、タスクと報酬のチェックを追加して、RL の学習や評価に使えます。
+
+[環境構築ガイド](https://rea.tools/guides/rl-environments/) ·
+[X でデモを見る](https://x.com/reatools/status/2112574822584918075?s=20)
+
 REA で興味深い対象を調べたら、ぜひ共有してください。[issue](https://github.com/morluto/rea/issues) または [pull request](https://github.com/morluto/rea/pulls) に、対象、調べたかったこと、REA がどう役立ったか、何が分かったかを記載してください。

+<a id="build-rl-environments"></a>
+
+## RL 環境を構築する
+
+元のアプリを動かさずに、AI エージェントが issue の検索やフォルダーの作成などを練習できるローカル環境を構築します。強化学習（RL）や、エージェントのタスク遂行能力のテストに使えます。
+
+REA は記録した API のリクエストと応答を、エージェントが呼び出せるツールに変換します。環境は記録したデータを使い、記録で効果が確認された変更だけをサポートします。
+
+エージェントに REA を設定したら、次の URL とフォルダー操作を自分の環境に合わせて変更してください。
+
+```text
+REA を使い、次のテスト用 Web アプリから RL 環境を構築してください。
+http://127.0.0.1:3000
+フォルダーの一覧表示、作成、名前変更、削除を対象にしてください。
+テスト用フォルダーの作成と削除は許可します。既存のデータは変更しないでください。
+my-env というフォルダーに保存し、使える操作を確認して実行方法を教えてください。
+```
+
+<details>
+<summary>コマンドラインを使う場合</summary>
+
+アプリのブラウザーリクエストと応答を記録したファイルがあれば、このコマンドを使えます。作成した環境の実行には AgentEnv と Docker も必要です。
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA は実行可能な環境と、起動して応答することを確認する基本テストをエクスポートします。RL フレームワークに接続して、タスクの目標や報酬のチェックを定義し、学習を実行できます。
+
+[環境構築ガイド](https://rea.tools/guides/rl-environments/) ·
+[環境リファレンス](../agent-environments.md) ·
+[X でデモを見る](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## よくある質問

 <details>
@@ -237,9 +282,9 @@ REA で興味深い対象を調べたら、ぜひ共有してください。[iss
 </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>

@@ -307,7 +352,7 @@ npx rea-agents@latest setup

 ## スター履歴

-🎉 **GitHub スター 300,000 件、ありがとうございます！**
+🎉 **GitHub スター 400,000 件、ありがとうございます！**

 REA の利用、バグ報告、機能の要望、ビルドのテスト、修正への貢献に感謝します。

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

 **[웹사이트](https://rea.tools/ko/) · [가이드](https://rea.tools/ko/guides/) · [사례](https://rea.tools/ko/showcase/)**

-[빠른 시작](#빠른-시작) · [REA의 작동 방식](#rea의-작동-방식) · [분석할 수 있는 대상](#분석할-수-있는-대상) · [사례](#사례) · [자주 묻는 질문](#자주-묻는-질문) · [문서](#문서)
+[빠른 시작](#빠른-시작) · [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 분석에는 네이티브 분석 엔진이 필요하지 않습니다.

 > <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)                                                       |
@@ -225,8 +225,51 @@ REA에는 Node.js 22.x(>=22.23.4), 24.x(>=24.22.1) 또는 26+ (>=26.12.1)와 npm
 [사례 읽기](https://rea.tools/ko/showcase/th04/) ·
 [재구현 저장소](https://github.com/N0zoM1z0/th04)

+### REA로 RL 환경 만들기
+
+웹 앱 세션을 기록하고 API를 도구로 바꿔 AI 에이전트가 사용할 수 있는 환경을 내보냅니다. AgentEnv로 실행한 뒤 작업과 보상 검사를 추가해 RL 학습이나 평가에 사용하세요.
+
+[환경 만들기 가이드](https://rea.tools/guides/rl-environments/) ·
+[X에서 데모 보기](https://x.com/reatools/status/2112574822584918075?s=20)
+
 REA로 흥미로운 대상을 분석했다면 알려 주세요. [issue](https://github.com/morluto/rea/issues) 또는 [pull request](https://github.com/morluto/rea/pulls)에 대상, 조사하려던 질문, REA가 어떻게 도움이 되었는지, 무엇을 알아냈는지를 담아 공유하세요.

+<a id="build-rl-environments"></a>
+
+## RL 환경 만들기
+
+원래 앱을 실행하지 않고도 AI 에이전트가 이슈 찾기나 폴더 만들기 같은 작업을 연습할 수 있는 로컬 환경을 만듭니다. 강화 학습(RL)이나 에이전트의 작업 수행 능력 평가에 사용할 수 있습니다.
+
+REA는 기록한 API 요청과 응답을 에이전트가 호출할 수 있는 도구로 바꿉니다. 환경은 기록된 데이터를 사용하며, 기록에서 효과가 확인된 변경만 지원합니다.
+
+에이전트에 REA를 설정한 뒤 아래 예시 URL과 폴더 작업을 자신의 환경에 맞게 바꾸세요.
+
+```text
+REA를 사용해 다음 테스트 웹 앱에서 RL 환경을 만들어 주세요.
+http://127.0.0.1:3000
+폴더 목록 조회, 생성, 이름 변경, 삭제를 포함해 주세요.
+테스트 폴더를 만들고 삭제해도 됩니다. 기존 데이터는 변경하지 마세요.
+my-env라는 폴더에 저장하고, 사용 가능한 작업을 확인한 뒤 실행 방법을 알려 주세요.
+```
+
+<details>
+<summary>명령줄을 사용하는 경우</summary>
+
+앱의 브라우저 요청과 응답을 기록한 파일이 이미 있으면 이 명령을 사용할 수 있습니다. 생성된 환경을 실행하려면 AgentEnv와 Docker도 필요합니다.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA는 실행 가능한 환경과 시작 및 응답 여부를 확인하는 기본 테스트를 내보냅니다. RL 프레임워크에 연결해 작업 목표와 보상 검사를 정의하고 학습을 실행할 수 있습니다.
+
+[환경 만들기 가이드](https://rea.tools/guides/rl-environments/) ·
+[환경 참조 문서](../agent-environments.md) ·
+[X에서 데모 보기](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## 자주 묻는 질문

 <details>
@@ -237,9 +280,9 @@ REA로 흥미로운 대상을 분석했다면 알려 주세요. [issue](https://
 </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>

@@ -307,7 +350,7 @@ npx rea-agents@latest setup

 ## 스타 기록

-🎉 **GitHub 스타 300,000개, 감사합니다!**
+🎉 **GitHub 스타 400,000개, 감사합니다!**

 REA를 사용하고, 버그를 보고하고, 기능을 요청하고, 빌드를 테스트하고, 수정에 기여해 주신 모든 분께 감사드립니다.

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

 **[വെബ്സൈറ്റ്](https://rea.tools/) · [ഗൈഡുകൾ](https://rea.tools/guides/) · [ഉദാഹരണങ്ങൾ](https://rea.tools/showcase/)**

-[ദ്രുതാരംഭം](#ദ്രുതാരംഭം) · [REA എങ്ങനെ പ്രവർത്തിക്കുന്നു](#rea-എങ്ങനെ-പ്രവർത്തിക്കുന്നു) · [എന്തൊക്കെ വിശകലനം ചെയ്യാം](#എന്തൊക്കെ-വിശകലനം-ചെയ്യാം) · [ഉദാഹരണങ്ങൾ](#ഉദാഹരണങ്ങൾ) · [പതിവുചോദ്യങ്ങൾ](#പതിവുചോദ്യങ്ങൾ) · [ഡോക്യുമെന്റേഷൻ](#ഡോക്യുമെന്റേഷൻ)
+[ദ്രുതാരംഭം](#ദ്രുതാരംഭം) · [REA എങ്ങനെ പ്രവർത്തിക്കുന്നു](#rea-എങ്ങനെ-പ്രവർത്തിക്കുന്നു) · [എന്തൊക്കെ വിശകലനം ചെയ്യാം](#എന്തൊക്കെ-വിശകലനം-ചെയ്യാം) · [ഉദാഹരണങ്ങൾ](#ഉദാഹരണങ്ങൾ) · [RL പരിതസ്ഥിതികൾ നിർമ്മിക്കുക](#build-rl-environments) · [പതിവുചോദ്യങ്ങൾ](#പതിവുചോദ്യങ്ങൾ) · [ഡോക്യുമെന്റേഷൻ](#ഡോക്യുമെന്റേഷൻ)

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

@@ -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)                                                  |
@@ -229,8 +229,51 @@ Renderer-ന്റെ clipboard API കണ്ടെത്തി, അതിനെ
 [Case study വായിക്കുക](https://rea.tools/showcase/th04/) ·
 [പുനർനിർമ്മാണ repository](https://github.com/N0zoM1z0/th04)

+### REA ഉപയോഗിച്ച് RL പരിതസ്ഥിതികൾ നിർമ്മിക്കുക
+
+വെബ് ആപ്പ് സെഷൻ റെക്കോർഡ് ചെയ്ത് API ടൂളുകളാക്കി AI ഏജന്റിന് ഉപയോഗിക്കാവുന്ന പരിതസ്ഥിതി എക്‌സ്‌പോർട്ട് ചെയ്യുക. AgentEnv ഉപയോഗിച്ച് പ്രവർത്തിപ്പിച്ച ശേഷം RL പരിശീലനത്തിനോ മൂല്യനിർണയത്തിനോ ടാസ്‌ക്കുകളും റിവാർഡ് പരിശോധനകളും ചേർക്കുക.
+
+[പരിതസ്ഥിതി നിർമ്മാണ മാർഗ്ഗദർശി](https://rea.tools/guides/rl-environments/) ·
+[X-ൽ ഡെമോ കാണുക](https://x.com/reatools/status/2112574822584918075?s=20)
+
 REA ഉപയോഗിച്ച് നിങ്ങൾ രസകരമായ എന്തെങ്കിലും പരിശോധിച്ചിട്ടുണ്ടെങ്കിൽ അത് കാണാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. പരിശോധിച്ച target, നിങ്ങളുടെ ചോദ്യം, REA എങ്ങനെ സഹായിച്ചു, നിങ്ങൾ കണ്ടെത്തിയത് എന്നിവ ഉൾപ്പെടുത്തി [issue](https://github.com/morluto/rea/issues) അല്ലെങ്കിൽ [pull request](https://github.com/morluto/rea/pulls) വഴി നിങ്ങളുടെ case പങ്കിടുക.

+<a id="build-rl-environments"></a>
+
+## RL പരിതസ്ഥിതികൾ നിർമ്മിക്കുക
+
+യഥാർഥ ആപ്പ് പ്രവർത്തിപ്പിക്കാതെ issue കണ്ടെത്തൽ, ഫോൾഡർ സൃഷ്ടിക്കൽ തുടങ്ങിയ ജോലികൾ AI ഏജന്റിന് പരിശീലിക്കാൻ ഒരു പ്രാദേശിക പരിതസ്ഥിതി നിർമ്മിക്കുക. റീഇൻഫോഴ്‌സ്‌മെന്റ് ലേണിംഗിനോ (RL) ഏജന്റ് ജോലികൾ എത്ര നന്നായി പൂർത്തിയാക്കുന്നു എന്ന് പരിശോധിക്കാനോ ഇത് ഉപയോഗിക്കാം.
+
+REA റെക്കോർഡ് ചെയ്ത API അഭ്യർത്ഥനകളും പ്രതികരണങ്ങളും ഏജന്റിന് വിളിക്കാവുന്ന ടൂളുകളാക്കുന്നു. പരിതസ്ഥിതി റെക്കോർഡ് ചെയ്ത ഡാറ്റ ഉപയോഗിക്കുന്നു. റെക്കോർഡ് ഫലം സ്ഥിരീകരിക്കുന്ന മാറ്റങ്ങൾ മാത്രമാണ് പിന്തുണയ്ക്കുന്നത്.
+
+ഏജന്റിൽ REA സജ്ജീകരിച്ച ശേഷം ഉദാഹരണത്തിലെ URL-ഉം ഫോൾഡർ ജോലികളും നിങ്ങളുടെ ആപ്പിന് അനുസരിച്ച് മാറ്റുക:
+
+```text
+എന്റെ പരീക്ഷണ വെബ് ആപ്പിൽ നിന്ന് REA ഉപയോഗിച്ച് RL പരിതസ്ഥിതി നിർമ്മിക്കുക:
+http://127.0.0.1:3000
+ഫോൾഡറുകൾ പട്ടികപ്പെടുത്തൽ, സൃഷ്ടിക്കൽ, പേരുമാറ്റൽ, ഇല്ലാതാക്കൽ എന്നിവ ഉൾപ്പെടുത്തുക.
+പരീക്ഷണ ഫോൾഡറുകൾ സൃഷ്ടിക്കാനും നീക്കാനും അനുമതിയുണ്ട്. നിലവിലുള്ള ഡാറ്റ മാറ്റരുത്.
+my-env എന്ന ഫോൾഡറിൽ സംരക്ഷിച്ച് ഏതെല്ലാം പ്രവർത്തനങ്ങൾ ലഭ്യമാണെന്നും എങ്ങനെ പ്രവർത്തിപ്പിക്കണമെന്നും പറയുക.
+```
+
+<details>
+<summary>കമാൻഡ് ലൈൻ ഉപയോഗിക്കുക</summary>
+
+ബ്രൗസറിലെ ആപ്പിന്റെ അഭ്യർത്ഥനകളും പ്രതികരണങ്ങളും റെക്കോർഡ് ചെയ്ത ഫയൽ ഉണ്ടെങ്കിൽ ഈ കമാൻഡുകൾ ഉപയോഗിക്കാം. ഫലം പ്രവർത്തിപ്പിക്കാൻ AgentEnv-ഉം Docker-ഉം വേണം.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+പ്രവർത്തനം തുടങ്ങുന്നതും പ്രതികരിക്കുന്നതും പരിശോധിക്കുന്ന അടിസ്ഥാന ടെസ്റ്റിനൊപ്പം പ്രവർത്തിപ്പിക്കാവുന്ന പരിതസ്ഥിതി REA എക്‌സ്‌പോർട്ട് ചെയ്യുന്നു. ടാസ്‌ക് ലക്ഷ്യങ്ങളും റിവാർഡ് പരിശോധനകളും നിർവചിക്കാനും പരിശീലനം നടത്താനും RL ഫ്രെയിംവർക്കുമായി ബന്ധിപ്പിക്കുക.
+
+[പരിതസ്ഥിതി നിർമ്മാണ മാർഗ്ഗദർശി](https://rea.tools/guides/rl-environments/) ·
+[പരിതസ്ഥിതി റഫറൻസ്](../agent-environments.md) ·
+[X-ൽ ഡെമോ കാണുക](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## പതിവുചോദ്യങ്ങൾ

 <details>
@@ -241,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>

@@ -312,7 +355,7 @@ npx rea-agents@latest setup

 ## Star ചരിത്രം

-🎉 **250,000 GitHub stars — നന്ദി!**
+🎉 **400,000 GitHub stars — നന്ദി!**

 REA ഉപയോഗിക്കുന്നവർക്കും, bugs റിപ്പോർട്ട് ചെയ്യുന്നവർക്കും, features ആവശ്യപ്പെടുന്നവർക്കും, builds പരിശോധിക്കുന്നവർക്കും, fixes സംഭാവന ചെയ്യുന്നവർക്കും നന്ദി.

@@ -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ń) · [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`.
@@ -223,8 +225,51 @@ Sprawdź 16-bitowe instrukcje oryginalnej gry na PC-98, odtwórz obliczenia kąt

 [Przeczytaj studium przypadku](https://rea.tools/pl/showcase/th04/) · [Repozytorium odtworzonej implementacji](https://github.com/N0zoM1z0/th04)

+### Twórz środowiska RL z REA
+
+Nagraj sesję aplikacji internetowej, zamień jej API w narzędzia i wyeksportuj środowisko dla agenta AI. Uruchom je za pomocą AgentEnv, a następnie dodaj zadania i sprawdzanie nagród do treningu RL lub oceny.
+
+[Przewodnik tworzenia środowiska](https://rea.tools/guides/rl-environments/) ·
+[Obejrzyj demo w X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 Jeśli użyłeś REA do czegoś ciekawego, chętnie to zobaczymy. Opisz swój przypadek w [zgłoszeniu](https://github.com/morluto/rea/issues) lub [pull requeście](https://github.com/morluto/rea/pulls), podając cel analizy, pytanie, sposób, w jaki REA pomogło, i swoje ustalenia.

+<a id="build-rl-environments"></a>
+
+## Tworzenie środowisk RL
+
+Stwórz lokalne środowisko, w którym agent AI może ćwiczyć zadania, takie jak wyszukiwanie zgłoszenia lub tworzenie folderu, bez uruchamiania oryginalnej aplikacji. Użyj go do uczenia ze wzmocnieniem (RL) lub sprawdzania, jak agent wykonuje zadania.
+
+REA zamienia nagrane żądania i odpowiedzi API w narzędzia, które agent może wywoływać. Środowisko używa nagranych danych i obsługuje zmiany tylko wtedy, gdy nagranie potwierdza ich efekty.
+
+Skonfiguruj REA w agencie, a następnie zastąp przykładowy URL i zadania dotyczące folderów własnymi:
+
+```text
+Za pomocą REA zbuduj środowisko RL z mojej testowej aplikacji internetowej:
+http://127.0.0.1:3000
+Uwzględnij wyświetlanie listy folderów, tworzenie, zmianę nazwy i usuwanie.
+Możesz tworzyć i usuwać foldery testowe. Nie zmieniaj istniejących danych.
+Zapisz w folderze my-env, sprawdź dostępne operacje i powiedz mi, jak uruchomić środowisko.
+```
+
+<details>
+<summary>Użyj wiersza poleceń</summary>
+
+Użyj tych poleceń, jeśli masz już plik z nagranymi żądaniami i odpowiedziami aplikacji w przeglądarce. Do uruchomienia wyniku potrzebujesz też AgentEnv i Dockera.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA eksportuje gotowe do uruchomienia środowisko z podstawowym testem uruchamiania i odpowiedzi. Połącz je ze swoim frameworkiem RL, aby określić cele zadań, dodać sprawdzanie nagród i uruchomić trening.
+
+[Przewodnik tworzenia środowiska](https://rea.tools/guides/rl-environments/) ·
+[Dokumentacja środowisk](../agent-environments.md) ·
+[Obejrzyj demo w X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## FAQ

 <details>
@@ -235,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>

@@ -305,7 +350,7 @@ Zgłaszaj podatności zgodnie z [SECURITY.md](../../SECURITY.md).

 ## Historia gwiazdek

-🎉 **300 000 gwiazdek na GitHubie — dziękujemy!**
+🎉 **400 000 gwiazdek na GitHubie — dziękujemy!**

 Dziękujemy wszystkim, którzy używają REA, zgłaszają błędy, proponują nowe funkcje, testują kompilacje i przesyłają poprawki.

@@ -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) · [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`.
@@ -223,8 +225,51 @@ Inspecione as instruções de 16 bits do jogo original para PC-98, recupere os c

 [Leia o estudo de caso](https://rea.tools/pt-BR/showcase/th04/) · [Repositório da reconstrução](https://github.com/N0zoM1z0/th04)

+### Criar ambientes de RL com o REA
+
+Grave uma sessão de aplicativo web, transforme sua API em ferramentas e exporte um ambiente que um agente de IA possa usar. Execute com o AgentEnv e adicione tarefas e verificações de recompensa para treinamento RL ou avaliação.
+
+[Guia para criar um ambiente](https://rea.tools/guides/rl-environments/) ·
+[Veja a demonstração no X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 Se você usou o REA em algo interessante, gostaríamos de conhecer. Compartilhe seu caso em uma [issue](https://github.com/morluto/rea/issues) ou um [pull request](https://github.com/morluto/rea/pulls), incluindo o alvo, sua pergunta, como o REA ajudou e o que descobriu.

+<a id="build-rl-environments"></a>
+
+## Criar ambientes de RL
+
+Crie um ambiente local onde um agente de IA possa praticar tarefas como encontrar uma issue ou criar uma pasta, sem executar o aplicativo original. Use para aprendizado por reforço (RL) ou para testar como o agente conclui tarefas.
+
+O REA transforma requisições e respostas de API gravadas em ferramentas que o agente pode chamar. O ambiente usa os dados gravados e só aceita alterações cujos efeitos sejam confirmados pela gravação.
+
+Configure o REA no agente e substitua a URL e as tarefas de pastas do exemplo pelas suas:
+
+```text
+Use o REA para criar um ambiente de RL a partir do meu aplicativo web de teste em
+http://127.0.0.1:3000.
+Inclua listar, criar, renomear e excluir pastas. Pode criar e remover
+pastas de teste, mas não altere os dados existentes.
+Salve em uma pasta chamada my-env, verifique quais operações funcionam e diga como executar.
+```
+
+<details>
+<summary>Usar a linha de comando</summary>
+
+Use estes comandos se já tiver um arquivo com as requisições e respostas do aplicativo gravadas no navegador. Para executar o resultado, você também precisa do AgentEnv e do Docker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+O REA exporta um ambiente executável com um teste básico para verificar se ele inicia e responde. Use com seu framework de RL para definir objetivos, adicionar verificações de recompensa e executar o treinamento.
+
+[Guia para criar um ambiente](https://rea.tools/guides/rl-environments/) ·
+[Referência de ambientes](../agent-environments.md) ·
+[Veja a demonstração no X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## Perguntas frequentes

 <details>
@@ -235,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>

@@ -305,7 +350,7 @@ Relate vulnerabilidades conforme [SECURITY.md](../../SECURITY.md).

 ## Histórico de estrelas

-🎉 **300.000 estrelas no GitHub — muito obrigado!**
+🎉 **400.000 estrelas no GitHub — muito obrigado!**

 Obrigado a todos que usam o REA, relatam bugs, sugerem funcionalidades, testam builds e contribuem com correções.

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

 **[Site web](https://rea.tools/) · [Ghiduri](https://rea.tools/guides/) · [Studii de caz](https://rea.tools/showcase/)**

-[Pornire rapidă](#pornire-rapidă) · [Cum funcționează REA](#cum-funcționează-rea) · [Ce poți analiza](#ce-poți-analiza) · [Studii de caz](#studii-de-caz) · [Întrebări frecvente](#întrebări-frecvente) · [Documentație](#documentație)
+[Pornire rapidă](#pornire-rapidă) · [Cum funcționează REA](#cum-funcționează-rea) · [Ce poți analiza](#ce-poți-analiza) · [Studii de caz](#studii-de-caz) · [Construiește medii RL](#build-rl-environments) · [Întrebări frecvente](#întrebări-frecvente) · [Documentație](#documentație)

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

@@ -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)                        |
@@ -282,11 +282,54 @@ compară codul C++ reconstruit cu rezultatul compilatorului folosit la acea vrem
 [Citește studiul de caz](https://rea.tools/showcase/th04/) ·
 [Repository-ul reconstrucției](https://github.com/N0zoM1z0/th04)

+### Construiește medii RL cu REA
+
+Înregistrează o sesiune de aplicație web, transformă API-ul în instrumente și exportă un mediu pe care un agent AI îl poate folosi. Rulează cu AgentEnv, apoi adaugă sarcini și verificări de recompensă pentru antrenare RL sau evaluare.
+
+[Ghid pentru construirea unui mediu](https://rea.tools/guides/rl-environments/) ·
+[Vezi demonstrația pe X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 Dacă ai folosit REA pentru ceva interesant, ne-ar plăcea să vedem rezultatul.
 Prezintă cazul într-un [issue](https://github.com/morluto/rea/issues) sau într-un
 [pull request](https://github.com/morluto/rea/pulls), menționând ținta analizată,
 întrebarea ta, cum te-a ajutat REA și ce ai descoperit.

+<a id="build-rl-environments"></a>
+
+## Construiește medii RL
+
+Creează un mediu local în care un agent AI să exerseze sarcini precum găsirea unui issue sau crearea unui dosar, fără a rula aplicația originală. Folosește-l pentru învățare prin recompensă (RL) sau pentru a testa cât de bine îndeplinește agentul sarcinile.
+
+REA transformă cererile și răspunsurile API înregistrate în instrumente pe care agentul le poate apela. Mediul folosește datele înregistrate și permite modificări doar când înregistrarea le confirmă efectele.
+
+După ce configurezi REA în agent, înlocuiește URL-ul și sarcinile pentru dosare din exemplu cu ale tale:
+
+```text
+Folosește REA pentru a crea un mediu RL din aplicația mea web de test de la
+http://127.0.0.1:3000.
+Include listarea, crearea, redenumirea și ștergerea dosarelor. Poți crea și elimina
+dosare de test, dar nu modifica datele existente.
+Salvează într-un dosar numit my-env, verifică operațiile disponibile și spune-mi cum îl rulez.
+```
+
+<details>
+<summary>Folosește linia de comandă</summary>
+
+Folosește aceste comenzi dacă ai deja un fișier cu cererile și răspunsurile aplicației înregistrate în browser. Pentru a rula rezultatul ai nevoie și de AgentEnv și Docker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA exportă un mediu executabil cu un test de bază care verifică pornirea și răspunsurile. Conectează-l la frameworkul RL pentru a defini obiectivele, a adăuga verificări de recompensă și a rula antrenarea.
+
+[Ghid pentru construirea unui mediu](https://rea.tools/guides/rl-environments/) ·
+[Referință pentru medii](../agent-environments.md) ·
+[Vezi demonstrația pe X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## Întrebări frecvente

 <details>
@@ -299,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>
@@ -386,7 +429,7 @@ Raportează vulnerabilitățile conform [SECURITY.md](../../SECURITY.md).

 ## Istoricul stelelor

-🎉 **300.000 de stele pe GitHub — vă mulțumim!**
+🎉 **400.000 de stele pe GitHub — vă mulțumim!**

 Mulțumim tuturor celor care folosesc REA, raportează erori, propun funcționalități,
 testează versiuni și contribuie cu remedieri.
@@ -20,7 +20,7 @@

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

-[Быстрый старт](#быстрый-старт) · [Как работает REA](#как-работает-rea) · [Что можно анализировать](#что-можно-анализировать) · [Примеры](#примеры) · [Частые вопросы](#частые-вопросы) · [Инструменты 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`.
@@ -223,8 +225,51 @@ REA требует Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) или 26+ (>=26.1

 [Прочитать исследование](https://rea.tools/ru/showcase/th04/) · [Репозиторий реконструкции](https://github.com/N0zoM1z0/th04)

+### Создавайте RL-окружения с REA
+
+Запишите сеанс веб-приложения, превратите его API в инструменты и экспортируйте окружение для ИИ-агента. Запустите его с AgentEnv, затем добавьте задания и проверки наград для RL-обучения или оценки.
+
+[Руководство по созданию окружения](https://rea.tools/guides/rl-environments/) ·
+[Смотреть демо в X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 Если вы исследовали с REA что-то интересное, поделитесь результатом. Создайте [issue](https://github.com/morluto/rea/issues) или [pull request](https://github.com/morluto/rea/pulls) и укажите цель, ваш вопрос, как помог REA и что удалось узнать.

+<a id="build-rl-environments"></a>
+
+## Создание RL-окружений
+
+Создайте локальное окружение, где ИИ-агент сможет выполнять пробные задания, например искать задачу в трекере или создавать папку, без запуска исходного приложения. Используйте его для обучения с подкреплением (RL) или проверки того, как агент справляется с заданиями.
+
+REA превращает записанные API-запросы и ответы в инструменты, которые может вызывать агент. Окружение использует записанные данные и поддерживает изменения только тогда, когда запись подтверждает их эффект.
+
+Настройте REA в своём агенте, затем замените пример URL и операции с папками на свои:
+
+```text
+С помощью REA создай RL-окружение из моего тестового веб-приложения:
+http://127.0.0.1:3000
+Включи просмотр списка папок, создание, переименование и удаление.
+Можно создавать и удалять тестовые папки. Существующие данные не меняй.
+Сохрани в папку my-env, проверь доступные операции и расскажи, как запустить окружение.
+```
+
+<details>
+<summary>Использовать командную строку</summary>
+
+Эти команды подходят, если у вас уже есть файл с записанными запросами и ответами приложения в браузере. Для запуска результата также нужны AgentEnv и Docker.
+
+```sh
+rea environment-build ./session.har ./my-env --name my-env --json
+agent-env run ./my-env
+```
+
+</details>
+
+REA экспортирует готовое к запуску окружение с базовым тестом запуска и ответов. Подключите его к своему RL-фреймворку, чтобы задать цели, добавить проверки наград и запустить обучение.
+
+[Руководство по созданию окружения](https://rea.tools/guides/rl-environments/) ·
+[Справочник окружений](../agent-environments.md) ·
+[Смотреть демо в X](https://x.com/reatools/status/2112574822584918075?s=20)
+
 ## Частые вопросы

 <details>
@@ -235,9 +280,9 @@ REA требует Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) или 26+ (>=26.1
 </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>

@@ -305,7 +350,7 @@ npx rea-agents@latest setup

 ## История звёзд

-🎉 **300 000 звёзд на GitHub — спасибо!**
+🎉 **400 000 звёзд на GitHub — спасибо!**

 Спасибо всем, кто использует REA, сообщает об ошибках, предлагает новые функции, тестирует сборки и помогает с исправлениями.