morluto/rea
1
0
Fork 0
mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00
Code Issues 1.3k Projects Packages Wiki Activity

[GH-ISSUE #778] [Docs] Track reproducible demos across REA reverse-engineering domains #337

New issue
Open
opened 2026-10-15 18:24:04 +00:00 by bsakaguchi · 6 comments
bsakaguchi commented 2026-10-15 18:24:04 +00:00
Owner
Copy link

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/778

Before submitting

  • I searched the existing issues for a related documentation report, including demo, walkthrough, and showcase proposals; no matching portfolio tracker was found.
  • I removed credentials, tokens, private paths, and sensitive target data.

Documentation location

README: product direction and quick start, tool catalog, the domain guides under docs/, and the bundled reverse-engineer-anything skill.

Proposed destination: a discoverable demo index linked from the README, with reproducible walkthroughs and recordings for selected analyst questions. The directory and recording format can be chosen during implementation.

Problem

REA — One MCP for reverse engineering across binaries, applications, and runtime behavior.

REA now covers substantially more than the Hopper workflow pictured in the README. At the initial review baseline, main commit 554e9b16, the generated catalog contains 125 MCP tools in 12 families, 80 primary CLI commands, and 18 provider descriptors. Those are inventory counts, not a claim that every provider or platform supports every operation.

Guides, examples, source-owned fixtures, and real verification scripts already exist. New users still need a coherent demonstration of how an analyst asks a question, selects a target, follows the evidence through several operations, and obtains a useful answer. A tool list or a passing verifier does not show that experience.

This issue tracks future demo work and provides a consistent way to select and add scenarios. It does not implement or record the demos now. The review for this issue inspected current contracts, catalog, guides, fixtures, and verification lanes; it did not rerun all domain toolchains.

Expected content

1. Select scenarios by the analyst outcome

Start each proposal with one concrete question. Identify the smallest target and observation that would let a viewer assess the answer. Then map that outcome to the current public CLI/MCP contracts and an independent fixture oracle.

Use these eligibility checks before scheduling a recording:

  • Answerable today: the required operation exists in the connected server's public contracts, on the exact proposed provider/host/target combination. Internal helpers, roadmap entries, and mock tests are not a substitute.
  • A checkable result: expected facts can be checked against source-owned source, known bytes/digests, a deliberate version change, or an explicitly captured result. State what remains inferred or unknown.
  • A shareable target: use a small, benign, source-owned or explicitly redistributable fixture. Record its origin, license, generation/download procedure, and digest. Do not base public recordings on a private local application or database.
  • A reproducible environment: name the tested REA artifact/commit, OS/architecture, provider version, and existing prerequisites. Keep fixture setup separate from the actual analysis and provide a focused stop/cleanup procedure.
  • A bounded experiment: estimate input size, working space, duration, and engine cost; run one heavy engine operation at a time. Measure actual resource use when verifying the script. Unknown budgets remain unknown until measured.

Among eligible proposals, prioritize:

Criterion Prefer Defer or simplify
Analyst value A recognizable question with a concrete answer A catalog tour or a sequence with no analytical conclusion
REA's contribution One REA connection, useful follow-ups, retained Evidence where supported, or a clear handoff between capabilities A recording dominated by unrelated engine installation or manual tool switching
Time to first result Small inputs and few steps after prerequisites are configured A large opaque application or lengthy analysis with no additional insight
Evidence clarity A visible source location, function, graph path, declared relationship, captured UI change, or deliberate difference A plausible narrative that cannot be checked from the returned evidence
Coverage added A new domain, useful boundary, or substantially different provider lifecycle Several engines repeating the same already-demonstrated result
Reproducibility Deterministic fixtures and a CLI equivalent for the demonstrated MCP workflow Machine-specific state, proprietary data, or fragile timing
Maintenance cost Existing fixtures, verifiers, and guides; an explicit reason for each extra dependency A new custom orchestration framework just for recording

These are review criteria, not invented benchmark scores. Give the selection rationale in each scenario entry; do not rank unmeasured scenarios using fabricated performance numbers.

2. Maintain a domain coverage matrix

All entries below are proposed, not completed demos. “Starter” is the suggested first batch; “Follow-up” and “Specialist” are candidates to revisit using the criteria above. Each domain can gain more rows when a distinct analyst outcome warrants one.

ID / batch Analyst question and intended result Existing public operations Fixture / verification starting point and important boundary
D01 / Starter — JavaScript and Electron static analysis Which modules handle a selected feature, and how do its IPC, configuration, or data relationships connect? Show one graph trace with source locations. analyze_javascript_application, trace_application_feature, trace_javascript_semantics Source-owned readiness JS/Electron trees; verify:application-workflows with explicit inputs. Static analysis needs no Hopper/Ghidra or target execution. Recovered relationships do not prove execution; unresolved dynamic relationships stay unknown.
D02 / Starter — Native binary analysis Which function implements a small computation or check, and what supports that explanation? Discover it, inspect pseudocode/assembly and references, then close the session. open_binary, search_strings, search_procedures, analyze_function, xrefs, close_binary Existing small C conformance sources and verify:ghidra / verify:hopper / verify:ida, as applicable. Pick one configured provider for the main story. A short optional IDA variant can contrast an already-open GUI target with an owned headless database. IDA's initial real coverage is Windows; Ghidra Windows P0 has its narrower native x64 PE/read-only boundary.
D03 / Starter — Browser behavior What changes when a user performs a selected action? Show the page result and captured activity, then compare a deliberately changed variant. inspect_web_page, observe_web_session, capture_browser_scenario, compare_web_captures / compare_web_screenshots A source-owned loopback web fixture and verify:browser. Keep passive inspection and active interaction distinct. Wait for an explicit result-ready condition and request DOM/screenshot capture when the page changes without navigating; final URL alone is insufficient.
D04 / Follow-up — Build/version differences What changed in a feature between two small application builds? Identify the paired entities, changed relationships or return shapes, and ambiguous matches. compare_application_versions, compare_source_to_bundle, compare_javascript_export_shapes Existing JS application fixtures and verify:application-workflows. Static differences are not behavioral equivalence; partial coverage cannot establish absence.
D05 / Follow-up — .NET PE/CLI Which managed members changed, and which native calls are declared? Show identity, metadata/CIL, and a deliberate member difference. inspect_managed_artifact, inspect_managed_members, inspect_managed_native_boundaries, compare_managed_members Existing byte-built managed fixtures and scripts/verify-managed-conformance.mjs. Do not load the assembly. Single-file unpacking, IL2CPP decoding, automatic original C# recovery, and managed runtime observation are outside the shipped parser scope.
D06 / Follow-up — Android APK What does the manifest declare, where is a selected method, and which incoming static references lead to it? inspect_android_package, search_android_classes, inspect_android_class, inspect_android_method, trace_android_references Public hash-pinned Appium ApiDemos; fixtures:android and verify:android, with existing Java/JADX. Linux is verified; Windows provider boundary is unsupported and macOS remains unverified. No emulator/APK execution, signature validation, or claim that static references are runtime calls.
D07 / Follow-up — Firmware to native code Which regions are reported, what files can be extracted, and how can one verified native child be analyzed through the same REA connection? inspect_firmware_regions, extract_firmware, then open_binary / analyze_function on a returned child Small source-generated gzip/USTAR fixture; fixtures:firmware and verify:firmware, with the separate optional Ghidra handoff lane. Current real coverage is Linux x64; Binwalk/Unblob/prlimit are supplied separately. Decompressed offsets are not original flash addresses; no hardware/emulation or unsupported-architecture claim.
D08 / Follow-up — Node/Electron runtime evidence Which scripts or contexts were observed, and how do they relate to the static application? Optionally capture a declared Electron action separately. list_javascript_runtime_targets, observe_javascript_runtime, reconcile_javascript_runtime; separate capture_electron_scenario Existing Inspector target fixture, verify:inspector, and the optional real verify:electron lane. Passive scriptParsed does not establish module execution, importing callers, or IPC events. Active Electron captures have different authority and lifecycle.
D09 / Follow-up — Process behavior and reconstruction Where do two declared command runs first differ? Preserve the difference, incomplete observations, and the remaining reconstruction obligations. capture_process_scenario, compare_process_captures, record_unknown, build_reconstruction_obligation_ledger, evaluate_reconstruction_coverage, Evidence bundle tools Source-owned readiness JS CLI and verify:readiness. Show a deliberate mismatch and an unknown. Selected filesystem snapshots are not syscall traces; complete equivalence is not inferred from matching partial captures. This is direct capture, not arbitrary replay execution.
D10 / Specialist — Apple resources and native UI How is a selected UI resource wired to a native handler? Show resource objects/dispatch evidence; add selected-window observation only on a verified host. inspect_artifact, decode_interface_builder, inspect_keyed_archive, inspect_asset_catalog, inspect_native_dispatch_metadata, trace_native_ui_action; optional observe_native_ui / capture_native_ui_scenario Source-owned XIB/Objective-C/Swift/window fixtures and their real macOS lanes. Asset tools and UI capture have host/tool prerequisites. Static wiring does not prove an action executed. A permission-denial test is not positive UI capture evidence.
D11 / Specialist — NativeAOT What recovered type relationships and virtual slots help explain a native function? Ghidra inspect_native_load_image, inspect_native_data_type, analyze_function Optional source-built NativeAOT fixtures and verify:ghidra:nativeaot. Tested scope is the documented .NET 8.0.22/RTR 9.1 x64 ELF/PE targets on Linux x64. Recovery modifies only ephemeral analysis memory; inferred names/layouts and derived ranges do not recover original C# or runtime state.
D12 / Specialist — DOS MZ/COM How do load addresses, file bytes and 16-bit function analysis relate? Ghidra open_binary, inspect_native_load_image, read_bytes, address_to_file_offset, analyze_function Generated MZ/COM fixtures; verify:ghidra:dos / verify:ghidra:com. Linux real workflows are verified. COM interpretation is explicit; analysis segment settings do not prove DOS/PC-98 runtime behavior.

The matrix intentionally does not enumerate every tool or every engine combination. Use the actual connected MCP tool list and session availability when writing a script. rea providers / rea capabilities alone do not inventory every application, Android, or browser workflow. Use open_binary for workflows whose contract requires a binary session; Android, firmware, browser and other explicit-object tools have their own inputs. Do not force all domains through one invented preparation flow.

3. Give every demo the same useful deliverables

  • A short analyst question and visible conclusion, followed by the evidence supporting it and any unresolved part.
  • One configured REA MCP connection and a real agent transcript, with an equivalent CLI recipe. Use existing same-connection Evidence references where advertised; do not require manual copying of large JSON records during the agent demo.
  • A compact written walkthrough, a recording or terminal capture, and a link from the demo index. Show representative results inline; keep full reproducibility instructions available alongside the recording.
  • Target source/provenance, exact generation or hash-verified download instructions, tested package version/commit and provider/host details. Verify the demonstrated artifact rather than assuming @latest includes repository main.
  • Actual time to first result, scenario duration, sampled process-family memory/CPU and working-space usage where measurable, plus cleanup outcome. Label estimates and samples precisely; do not present them as hard engine limits.
  • A focused negative/control observation when relevant: for example an ambiguous match, unsupported facet, deliberately changed output, or incomplete capture. Show the corresponding actionable result without turning the walkthrough into a permission/setup checklist.
  • Public material checked for machine-specific paths, credentials, private code, and unrelated desktop/browser data. Use a clean recording workspace and shareable targets. Label edited output as an excerpt; do not present a modified Evidence payload as an authenticated original.

4. Keep this issue easy to extend

Use statuses Proposed, Selected, Scripted, Verified, Recorded, and Published; use Blocked with a concrete prerequisite or linked defect. “Verified” requires the actual advertised workflow on its declared host/provider. A mock or permission-denial result covers only its stated narrower boundary.

Copy this block for a new scenario or replace it with a link to the resulting walkthrough/PR:

#### Dxx — <scenario title>
- Status / owner:
- Analyst question / expected answer:
- Why select it / coverage added:
- Target source, license, digest and generation procedure:
- Public REA operations / CLI recipe:
- Host, REA artifact and provider prerequisites:
- Independent oracle / meaningful unknown or control:
- Estimated cost; measured time, CPU/RSS, temporary/output space:
- Lifecycle and cleanup result:
- Verification command / report:
- Script, recording, documentation and PR links:
- Blocker or next action:

Keep the domain matrix and task list current. Add a new row for a distinct question; add a provider variant to an existing scenario when the outcome is unchanged. Link existing capability defects instead of duplicating them. Split out an implementation issue only when a scenario reveals substantial code work, and link it here while keeping the demo status explicit.

Initial task list and completion criteria

  • Confirm the starter questions, fixture choices, and selection rationale for D01–D03.
  • Write reproducible scripts/walkthroughs for the starter demos using current public contracts.
  • Verify the demonstrated package and real workflows, including cleanup, evidence limits, and measured resource cost.
  • Record the starter demos and publish a README-linked index with equivalent CLI recipes.
  • Test the documented paths as a new user with only the stated prerequisites; record and link usability failures.
  • Fill in ownership, next action and priority rationale for the follow-up/specialist matrix; keep deferred rows visible.
  • Document how to add/update a scenario and what invalidates its previous verification (contract, fixture, provider or host changes).

The initial deliverable is a reproducible starter portfolio plus a maintained extension path, not 125 individual tool videos. This issue can close once the starter portfolio is published and remaining candidates have explicit follow-up links or deferral records; future additions can use the same template.

Supporting evidence

Additional context

Related product direction: #32. Investigation/capability organization is tracked separately in #740; this demo portfolio can proceed without waiting for that refactor. Domain provider work is referenced in #717, #718, and the merged IDA integration #747/#754; demo status must follow actual current contracts and verification rather than those issues' open/closed state.

Suggested labels: documentation, triage, P2: medium, area: cli, area: mcp, area: tests. This is one documentation/demo tracking issue; separate subissues are unnecessary until a concrete demo needs substantial implementation work.

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/778 ### Before submitting - [x] I searched the existing issues for a related documentation report, including demo, walkthrough, and showcase proposals; no matching portfolio tracker was found. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Documentation location [README: product direction and quick start](https://github.com/morluto/rea/blob/main/README.md), [tool catalog](https://github.com/morluto/rea/blob/main/docs/product-catalog.json), the domain guides under `docs/`, and the bundled `reverse-engineer-anything` skill. Proposed destination: a discoverable demo index linked from the README, with reproducible walkthroughs and recordings for selected analyst questions. The directory and recording format can be chosen during implementation. ### Problem > REA — One MCP for reverse engineering across binaries, applications, and runtime behavior. REA now covers substantially more than the Hopper workflow pictured in the README. At the initial review baseline, main commit [`554e9b16`](https://github.com/morluto/rea/commit/554e9b1612f7799c2bc7177eb1a9b04a0f27d2e9), the generated catalog contains 125 MCP tools in 12 families, 80 primary CLI commands, and 18 provider descriptors. Those are inventory counts, not a claim that every provider or platform supports every operation. Guides, examples, source-owned fixtures, and real verification scripts already exist. New users still need a coherent demonstration of how an analyst asks a question, selects a target, follows the evidence through several operations, and obtains a useful answer. A tool list or a passing verifier does not show that experience. This issue tracks future demo work and provides a consistent way to select and add scenarios. It does not implement or record the demos now. The review for this issue inspected current contracts, catalog, guides, fixtures, and verification lanes; it did not rerun all domain toolchains. ### Expected content #### 1. Select scenarios by the analyst outcome Start each proposal with one concrete question. Identify the smallest target and observation that would let a viewer assess the answer. Then map that outcome to the current public CLI/MCP contracts and an independent fixture oracle. Use these eligibility checks before scheduling a recording: - **Answerable today:** the required operation exists in the connected server's public contracts, on the exact proposed provider/host/target combination. Internal helpers, roadmap entries, and mock tests are not a substitute. - **A checkable result:** expected facts can be checked against source-owned source, known bytes/digests, a deliberate version change, or an explicitly captured result. State what remains inferred or unknown. - **A shareable target:** use a small, benign, source-owned or explicitly redistributable fixture. Record its origin, license, generation/download procedure, and digest. Do not base public recordings on a private local application or database. - **A reproducible environment:** name the tested REA artifact/commit, OS/architecture, provider version, and existing prerequisites. Keep fixture setup separate from the actual analysis and provide a focused stop/cleanup procedure. - **A bounded experiment:** estimate input size, working space, duration, and engine cost; run one heavy engine operation at a time. Measure actual resource use when verifying the script. Unknown budgets remain unknown until measured. Among eligible proposals, prioritize: | Criterion | Prefer | Defer or simplify | | --- | --- | --- | | Analyst value | A recognizable question with a concrete answer | A catalog tour or a sequence with no analytical conclusion | | REA's contribution | One REA connection, useful follow-ups, retained Evidence where supported, or a clear handoff between capabilities | A recording dominated by unrelated engine installation or manual tool switching | | Time to first result | Small inputs and few steps after prerequisites are configured | A large opaque application or lengthy analysis with no additional insight | | Evidence clarity | A visible source location, function, graph path, declared relationship, captured UI change, or deliberate difference | A plausible narrative that cannot be checked from the returned evidence | | Coverage added | A new domain, useful boundary, or substantially different provider lifecycle | Several engines repeating the same already-demonstrated result | | Reproducibility | Deterministic fixtures and a CLI equivalent for the demonstrated MCP workflow | Machine-specific state, proprietary data, or fragile timing | | Maintenance cost | Existing fixtures, verifiers, and guides; an explicit reason for each extra dependency | A new custom orchestration framework just for recording | These are review criteria, not invented benchmark scores. Give the selection rationale in each scenario entry; do not rank unmeasured scenarios using fabricated performance numbers. #### 2. Maintain a domain coverage matrix All entries below are **proposed**, not completed demos. “Starter” is the suggested first batch; “Follow-up” and “Specialist” are candidates to revisit using the criteria above. Each domain can gain more rows when a distinct analyst outcome warrants one. | ID / batch | Analyst question and intended result | Existing public operations | Fixture / verification starting point and important boundary | | --- | --- | --- | --- | | D01 / Starter — JavaScript and Electron static analysis | Which modules handle a selected feature, and how do its IPC, configuration, or data relationships connect? Show one graph trace with source locations. | `analyze_javascript_application`, `trace_application_feature`, `trace_javascript_semantics` | Source-owned readiness JS/Electron trees; `verify:application-workflows` with explicit inputs. Static analysis needs no Hopper/Ghidra or target execution. Recovered relationships do not prove execution; unresolved dynamic relationships stay unknown. | | D02 / Starter — Native binary analysis | Which function implements a small computation or check, and what supports that explanation? Discover it, inspect pseudocode/assembly and references, then close the session. | `open_binary`, `search_strings`, `search_procedures`, `analyze_function`, `xrefs`, `close_binary` | Existing small C conformance sources and `verify:ghidra` / `verify:hopper` / `verify:ida`, as applicable. Pick one configured provider for the main story. A short optional IDA variant can contrast an already-open GUI target with an owned headless database. IDA's initial real coverage is Windows; Ghidra Windows P0 has its narrower native x64 PE/read-only boundary. | | D03 / Starter — Browser behavior | What changes when a user performs a selected action? Show the page result and captured activity, then compare a deliberately changed variant. | `inspect_web_page`, `observe_web_session`, `capture_browser_scenario`, `compare_web_captures` / `compare_web_screenshots` | A source-owned loopback web fixture and `verify:browser`. Keep passive inspection and active interaction distinct. Wait for an explicit result-ready condition and request DOM/screenshot capture when the page changes without navigating; final URL alone is insufficient. | | D04 / Follow-up — Build/version differences | What changed in a feature between two small application builds? Identify the paired entities, changed relationships or return shapes, and ambiguous matches. | `compare_application_versions`, `compare_source_to_bundle`, `compare_javascript_export_shapes` | Existing JS application fixtures and `verify:application-workflows`. Static differences are not behavioral equivalence; partial coverage cannot establish absence. | | D05 / Follow-up — .NET PE/CLI | Which managed members changed, and which native calls are declared? Show identity, metadata/CIL, and a deliberate member difference. | `inspect_managed_artifact`, `inspect_managed_members`, `inspect_managed_native_boundaries`, `compare_managed_members` | Existing byte-built managed fixtures and `scripts/verify-managed-conformance.mjs`. Do not load the assembly. Single-file unpacking, IL2CPP decoding, automatic original C# recovery, and managed runtime observation are outside the shipped parser scope. | | D06 / Follow-up — Android APK | What does the manifest declare, where is a selected method, and which incoming static references lead to it? | `inspect_android_package`, `search_android_classes`, `inspect_android_class`, `inspect_android_method`, `trace_android_references` | Public hash-pinned Appium ApiDemos; `fixtures:android` and `verify:android`, with existing Java/JADX. Linux is verified; Windows provider boundary is unsupported and macOS remains unverified. No emulator/APK execution, signature validation, or claim that static references are runtime calls. | | D07 / Follow-up — Firmware to native code | Which regions are reported, what files can be extracted, and how can one verified native child be analyzed through the same REA connection? | `inspect_firmware_regions`, `extract_firmware`, then `open_binary` / `analyze_function` on a returned child | Small source-generated gzip/USTAR fixture; `fixtures:firmware` and `verify:firmware`, with the separate optional Ghidra handoff lane. Current real coverage is Linux x64; Binwalk/Unblob/prlimit are supplied separately. Decompressed offsets are not original flash addresses; no hardware/emulation or unsupported-architecture claim. | | D08 / Follow-up — Node/Electron runtime evidence | Which scripts or contexts were observed, and how do they relate to the static application? Optionally capture a declared Electron action separately. | `list_javascript_runtime_targets`, `observe_javascript_runtime`, `reconcile_javascript_runtime`; separate `capture_electron_scenario` | Existing Inspector target fixture, `verify:inspector`, and the optional real `verify:electron` lane. Passive `scriptParsed` does not establish module execution, importing callers, or IPC events. Active Electron captures have different authority and lifecycle. | | D09 / Follow-up — Process behavior and reconstruction | Where do two declared command runs first differ? Preserve the difference, incomplete observations, and the remaining reconstruction obligations. | `capture_process_scenario`, `compare_process_captures`, `record_unknown`, `build_reconstruction_obligation_ledger`, `evaluate_reconstruction_coverage`, Evidence bundle tools | Source-owned readiness JS CLI and `verify:readiness`. Show a deliberate mismatch and an unknown. Selected filesystem snapshots are not syscall traces; complete equivalence is not inferred from matching partial captures. This is direct capture, not arbitrary replay execution. | | D10 / Specialist — Apple resources and native UI | How is a selected UI resource wired to a native handler? Show resource objects/dispatch evidence; add selected-window observation only on a verified host. | `inspect_artifact`, `decode_interface_builder`, `inspect_keyed_archive`, `inspect_asset_catalog`, `inspect_native_dispatch_metadata`, `trace_native_ui_action`; optional `observe_native_ui` / `capture_native_ui_scenario` | Source-owned XIB/Objective-C/Swift/window fixtures and their real macOS lanes. Asset tools and UI capture have host/tool prerequisites. Static wiring does not prove an action executed. A permission-denial test is not positive UI capture evidence. | | D11 / Specialist — NativeAOT | What recovered type relationships and virtual slots help explain a native function? | Ghidra `inspect_native_load_image`, `inspect_native_data_type`, `analyze_function` | Optional source-built NativeAOT fixtures and `verify:ghidra:nativeaot`. Tested scope is the documented .NET 8.0.22/RTR 9.1 x64 ELF/PE targets on Linux x64. Recovery modifies only ephemeral analysis memory; inferred names/layouts and derived ranges do not recover original C# or runtime state. | | D12 / Specialist — DOS MZ/COM | How do load addresses, file bytes and 16-bit function analysis relate? | Ghidra `open_binary`, `inspect_native_load_image`, `read_bytes`, `address_to_file_offset`, `analyze_function` | Generated MZ/COM fixtures; `verify:ghidra:dos` / `verify:ghidra:com`. Linux real workflows are verified. COM interpretation is explicit; analysis segment settings do not prove DOS/PC-98 runtime behavior. | The matrix intentionally does not enumerate every tool or every engine combination. Use the actual connected MCP tool list and session availability when writing a script. `rea providers` / `rea capabilities` alone do not inventory every application, Android, or browser workflow. Use `open_binary` for workflows whose contract requires a binary session; Android, firmware, browser and other explicit-object tools have their own inputs. Do not force all domains through one invented preparation flow. #### 3. Give every demo the same useful deliverables - A short analyst question and visible conclusion, followed by the evidence supporting it and any unresolved part. - One configured REA MCP connection and a real agent transcript, with an equivalent CLI recipe. Use existing same-connection Evidence references where advertised; do not require manual copying of large JSON records during the agent demo. - A compact written walkthrough, a recording or terminal capture, and a link from the demo index. Show representative results inline; keep full reproducibility instructions available alongside the recording. - Target source/provenance, exact generation or hash-verified download instructions, tested package version/commit and provider/host details. Verify the demonstrated artifact rather than assuming `@latest` includes repository main. - Actual time to first result, scenario duration, sampled process-family memory/CPU and working-space usage where measurable, plus cleanup outcome. Label estimates and samples precisely; do not present them as hard engine limits. - A focused negative/control observation when relevant: for example an ambiguous match, unsupported facet, deliberately changed output, or incomplete capture. Show the corresponding actionable result without turning the walkthrough into a permission/setup checklist. - Public material checked for machine-specific paths, credentials, private code, and unrelated desktop/browser data. Use a clean recording workspace and shareable targets. Label edited output as an excerpt; do not present a modified Evidence payload as an authenticated original. #### 4. Keep this issue easy to extend Use statuses `Proposed`, `Selected`, `Scripted`, `Verified`, `Recorded`, and `Published`; use `Blocked` with a concrete prerequisite or linked defect. “Verified” requires the actual advertised workflow on its declared host/provider. A mock or permission-denial result covers only its stated narrower boundary. Copy this block for a new scenario or replace it with a link to the resulting walkthrough/PR: ```markdown #### Dxx — <scenario title> - Status / owner: - Analyst question / expected answer: - Why select it / coverage added: - Target source, license, digest and generation procedure: - Public REA operations / CLI recipe: - Host, REA artifact and provider prerequisites: - Independent oracle / meaningful unknown or control: - Estimated cost; measured time, CPU/RSS, temporary/output space: - Lifecycle and cleanup result: - Verification command / report: - Script, recording, documentation and PR links: - Blocker or next action: ``` Keep the domain matrix and task list current. Add a new row for a distinct question; add a provider variant to an existing scenario when the outcome is unchanged. Link existing capability defects instead of duplicating them. Split out an implementation issue only when a scenario reveals substantial code work, and link it here while keeping the demo status explicit. #### Initial task list and completion criteria - [ ] Confirm the starter questions, fixture choices, and selection rationale for D01–D03. - [ ] Write reproducible scripts/walkthroughs for the starter demos using current public contracts. - [ ] Verify the demonstrated package and real workflows, including cleanup, evidence limits, and measured resource cost. - [ ] Record the starter demos and publish a README-linked index with equivalent CLI recipes. - [ ] Test the documented paths as a new user with only the stated prerequisites; record and link usability failures. - [ ] Fill in ownership, next action and priority rationale for the follow-up/specialist matrix; keep deferred rows visible. - [ ] Document how to add/update a scenario and what invalidates its previous verification (contract, fixture, provider or host changes). The initial deliverable is a reproducible starter portfolio plus a maintained extension path, not 125 individual tool videos. This issue can close once the starter portfolio is published and remaining candidates have explicit follow-up links or deferral records; future additions can use the same template. ### Supporting evidence - [Baseline catalog](https://github.com/morluto/rea/blob/554e9b1612f7799c2bc7177eb1a9b04a0f27d2e9/docs/product-catalog.json): exact source-generated tool families, provider coverage, and CLI inventory. - [Testing guide](https://github.com/morluto/rea/blob/main/docs/testing.md) and [source-owned conformance fixtures](https://github.com/morluto/rea/tree/main/tests/conformance): existing real lanes and their precise proof boundaries. - [JavaScript workflows](https://github.com/morluto/rea/blob/main/docs/javascript-application-workflows.md), [browser scenarios](https://github.com/morluto/rea/blob/main/docs/browser-scenario-contract.md), and [reconstruction readiness](https://github.com/morluto/rea/blob/main/docs/reconstruction-readiness.md). - [IDA](https://github.com/morluto/rea/blob/main/docs/ida-provider.md), [Android](https://github.com/morluto/rea/blob/main/docs/android-analysis.md), [firmware](https://github.com/morluto/rea/blob/main/docs/firmware-analysis.md), [.NET](https://github.com/morluto/rea/blob/main/docs/managed-code-analysis.md), [NativeAOT](https://github.com/morluto/rea/blob/main/docs/ghidra-nativeaot.md), [native/Apple investigation](https://github.com/morluto/rea/blob/main/docs/native-investigation.md), and [DOS](https://github.com/morluto/rea/blob/main/docs/ghidra-dos.md) guides. ### Additional context Related product direction: #32. Investigation/capability organization is tracked separately in #740; this demo portfolio can proceed without waiting for that refactor. Domain provider work is referenced in #717, #718, and the merged IDA integration #747/#754; demo status must follow actual current contracts and verification rather than those issues' open/closed state. Suggested labels: `documentation`, `triage`, `P2: medium`, `area: cli`, `area: mcp`, `area: tests`. This is one documentation/demo tracking issue; separate subissues are unnecessary until a concrete demo needs substantial implementation work.
bsakaguchi commented 2026-10-15 18:24:05 +00:00
Author
Owner
Copy link

@014-code commented on GitHub (Oct 11, 2026):

Implementation update for D01-D03: PR #1704. I kept the issue open because several requested proof items still need real provider, agent and recording runs.

I worked through the scenarios in this order:

  1. I checked the current public CLI/MCP contracts, the existing source-owned examples and the verifier lanes, then used the three starter questions already listed here. The implementation adds a README-linked demo page, a guide-hub entry and a separate evidence record rather than treating a verifier report as a published recording or benchmark.

  2. For D01, I analyzed the six-file Notes Electron fixture with the public CLI and saved the analysis, feature-trace and semantic-trace Evidence IDs in the evidence record. The application graph had 29 nodes and 42 edges; tracing the exact notes:export feature returned complete coverage of all 29 nodes and 42 edges. A forward-influence semantic query seeded by property invoke was ambiguous, partial and had one relevant unknown. A literal semantic seed for notes:export had no match, so the page keeps the IPC channel claim tied to the application graph rather than presenting that string as a semantic result.

    The source-backed data flow is renderer.js -> preload.js -> main.js -> csv.js: the renderer calls window.notes.exportCsv(), the preload invokes notes:export, and the main handler writes notes.csv under Electron's Downloads path. The CSV writer emits the id,title header and note rows; the handler returns the destination for the renderer's status message. This is static analysis, so it does not prove that a click or write occurred or resolve the actual Downloads path. I also extended the agent evaluation scenario to require the analysis, feature trace and semantic query in order. A usable real Codex transcript was not available on this host, so I did not claim that agent workflow as verified.

    Evidence IDs: analysis ev_46841fb660ac9c02a2932b465177397114a4aaaed9fecdebd79b6904d976bd30; feature trace ev_3ece6d552f75f7d4ecb4e303e12703dec3a966a1d479fd1c3aad4685dce68b5e; semantic trace ev_68c6438a3907198bd130fe5b7fd7fb201372dbd1ab80311a4fd131e97210b6f8. The root artifact SHA-256 is 3c11d59338104ba96399bfd05bebf4359ac6a293f49d2b095566456842f4396e.

  3. For D02, I used the existing C conformance fixture (rea_entry -> rea_branch -> rea_leaf) and documented fixture generation, integrity checks, Ghidra CLI steps, the corresponding MCP lifecycle and close_binary cleanup. This Windows host had neither a C compiler nor a configured Ghidra, IDA or Hopper provider. I therefore recorded the provider run as blocked and did not invent pseudocode, references or a cleanup result.

  4. For D03, I added a loopback-only /portfolio-demo route whose Export notes button displays Exported 2 notes or Exported 3 notes. The real-browser verifier launches Chrome for both variants, clicks the same button, waits for the result-ready DOM state, captures the DOM through the public CLI and runs compare-web-captures on the normalized results. Run b8b2d376-d5a4-495a-b558-dedfc0884d1d used Node.js 24.18.0, npm 11.16.0 and Chrome 154.0.8037.99. The captures aligned, the overall status was changed, and the result step had one changed DOM artifact. The verifier terminated its owned Chrome processes, removed both temporary profiles and comparison inputs, and closed the page proxy and fixture server.

Validation performed: npm run build:cached, npm run check:fast, npm run verify:windows-native:artifact, and npm run verify:browser passed. python scripts/website.py check passed with 20 HTML pages, 437 local references, sitemap/metadata checks and 7 maintenance tests. Scoped Oxfmt checks on the 9 changed files, git diff --check, the pre-commit format/lint hooks and the pre-push check:fast passed. The full-repository npm run format:check flags even unchanged CONTRIBUTING.md in this Windows checkout because core.autocrlf=true; the PR files pass the scoped formatter check.

Still outstanding for this issue: a real D01 agent transcript with retained Evidence citations, a real D02 provider run with cleanup evidence, walkthrough recordings, a clean-user setup run, and measured time/CPU/RSS/temporary-space costs. These gaps and their boundaries are visible in the new evidence record; this PR does not claim the issue is complete.

<!-- gh-comment-id:6105676975 --> @014-code commented on GitHub (Oct 11, 2026): Implementation update for D01-D03: [PR #1704](https://github.com/morluto/rea/pull/1704). I kept the issue open because several requested proof items still need real provider, agent and recording runs. I worked through the scenarios in this order: 1. I checked the current public CLI/MCP contracts, the existing source-owned examples and the verifier lanes, then used the three starter questions already listed here. The implementation adds a README-linked demo page, a guide-hub entry and a separate evidence record rather than treating a verifier report as a published recording or benchmark. 2. For D01, I analyzed the six-file Notes Electron fixture with the public CLI and saved the analysis, feature-trace and semantic-trace Evidence IDs in the evidence record. The application graph had 29 nodes and 42 edges; tracing the exact `notes:export` feature returned complete coverage of all 29 nodes and 42 edges. A forward-influence semantic query seeded by property `invoke` was ambiguous, partial and had one relevant unknown. A literal semantic seed for `notes:export` had no match, so the page keeps the IPC channel claim tied to the application graph rather than presenting that string as a semantic result. The source-backed data flow is `renderer.js` -> `preload.js` -> `main.js` -> `csv.js`: the renderer calls `window.notes.exportCsv()`, the preload invokes `notes:export`, and the main handler writes `notes.csv` under Electron's Downloads path. The CSV writer emits the `id,title` header and note rows; the handler returns the destination for the renderer's status message. This is static analysis, so it does not prove that a click or write occurred or resolve the actual Downloads path. I also extended the agent evaluation scenario to require the analysis, feature trace and semantic query in order. A usable real Codex transcript was not available on this host, so I did not claim that agent workflow as verified. Evidence IDs: analysis `ev_46841fb660ac9c02a2932b465177397114a4aaaed9fecdebd79b6904d976bd30`; feature trace `ev_3ece6d552f75f7d4ecb4e303e12703dec3a966a1d479fd1c3aad4685dce68b5e`; semantic trace `ev_68c6438a3907198bd130fe5b7fd7fb201372dbd1ab80311a4fd131e97210b6f8`. The root artifact SHA-256 is `3c11d59338104ba96399bfd05bebf4359ac6a293f49d2b095566456842f4396e`. 3. For D02, I used the existing C conformance fixture (`rea_entry` -> `rea_branch` -> `rea_leaf`) and documented fixture generation, integrity checks, Ghidra CLI steps, the corresponding MCP lifecycle and `close_binary` cleanup. This Windows host had neither a C compiler nor a configured Ghidra, IDA or Hopper provider. I therefore recorded the provider run as blocked and did not invent pseudocode, references or a cleanup result. 4. For D03, I added a loopback-only `/portfolio-demo` route whose Export notes button displays `Exported 2 notes` or `Exported 3 notes`. The real-browser verifier launches Chrome for both variants, clicks the same button, waits for the result-ready DOM state, captures the DOM through the public CLI and runs `compare-web-captures` on the normalized results. Run `b8b2d376-d5a4-495a-b558-dedfc0884d1d` used Node.js 24.18.0, npm 11.16.0 and Chrome 154.0.8037.99. The captures aligned, the overall status was `changed`, and the result step had one changed DOM artifact. The verifier terminated its owned Chrome processes, removed both temporary profiles and comparison inputs, and closed the page proxy and fixture server. Validation performed: `npm run build:cached`, `npm run check:fast`, `npm run verify:windows-native:artifact`, and `npm run verify:browser` passed. `python scripts/website.py check` passed with 20 HTML pages, 437 local references, sitemap/metadata checks and 7 maintenance tests. Scoped Oxfmt checks on the 9 changed files, `git diff --check`, the pre-commit format/lint hooks and the pre-push `check:fast` passed. The full-repository `npm run format:check` flags even unchanged `CONTRIBUTING.md` in this Windows checkout because `core.autocrlf=true`; the PR files pass the scoped formatter check. Still outstanding for this issue: a real D01 agent transcript with retained Evidence citations, a real D02 provider run with cleanup evidence, walkthrough recordings, a clean-user setup run, and measured time/CPU/RSS/temporary-space costs. These gaps and their boundaries are visible in the new evidence record; this PR does not claim the issue is complete.
bsakaguchi commented 2026-10-15 18:24:05 +00:00
Author
Owner
Copy link

@0xRafie commented on GitHub (Oct 12, 2026):

Verification record for D03 (browser behavior): notes-web demo on two Chromium-family browsers, using the scenario block from this issue.

D03 — notes-web Export notes, connect mode on Chrome and Brave

  • Status / owner: Verified on one host (macOS); not recorded.
  • Analyst question / expected answer: What does "Export notes" do? It fetches notes.json (200), builds a CSV in the page, and the status reads "Exported 2 notes to notes.csv.".
  • Why select it / coverage added: the D03 record in PR #1704 uses launch mode with Chrome 154. This adds a connect-mode variant (an existing loopback browser) and a second Chromium-family browser (Brave).
  • Target source, license, digest and generation procedure: website/public/examples/notes-web/ from main d96550f, served with python3 -m http.server --bind 127.0.0.1 8791 from website/public. export.js sha256 66f5c2501bfca72eb743a1fffbdce9a58d295e69ca66f19562e9b0fa9fc189a6 (925 bytes). REA's captured source digest matches the file.
  • Public REA operations / CLI recipe: 
    "<browser executable>" --headless=new --use-mock-keychain --no-first-run --no-default-browser-check \
  --user-data-dir="$(mktemp -d)" --remote-debugging-port=<port> http://127.0.0.1:8791/examples/notes-web/
rea list-browser-targets http://127.0.0.1:<port>
rea capture-browser-scenario scenario.json
rea inspect-web-event-listeners http://127.0.0.1:<port> <target_id> '#export'
    scenario.json: 
    {"browser":{"mode":"connect","cdp_endpoint":"http://127.0.0.1:<port>","target_id":"<target_id>"},
 "start_url":{"url":"http://127.0.0.1:8791/examples/notes-web/"},
 "actions":[{"step_id":"export","action":"click","locator":{"kind":"css","selector":"#export"},"timeout_ms":10000},
            {"step_id":"wait","action":"wait_for_timeout","duration_ms":500}],
 "capture":{"events":["network"],"network":{"response_body":true},"at_end":["dom","url"]}}
  • Host, REA artifact and provider prerequisites: macOS 26.7.1 (25G241); REA 6.4.0 built from main d96550f (node scripts/rea.mjs); Node 26.9.0. Browsers: Google Chrome 154.0.8037.99 and Brave Browser 155.1.97.56 (Chromium 155.0.8059.40), both headless.
  • Independent oracle / meaningful unknown or control:
    • Scenario, both browsers: steps scenario_start, export, wait completed. In the export step: GET http://127.0.0.1:8791/examples/notes-web/notes.json, resource_type fetch, response status 200. The final DOM status reads "Exported 2 notes to notes.csv." and matches the handler in export.js.
    • Listeners, both browsers: one click listener on #export at export.js line 0, column 60 (source_association: script_id).
    • Initiator: scenario events carry none (limitation: "Playwright scenario events do not expose request initiator stacks"). A passive inspect-web-page (4 s window) while the button was clicked through a separate CDP Runtime.evaluate reported notes.json GET Fetch 200 with initiator {type: script, url: .../notes-web/export.js, line: 3, column: 27} (Chrome only).
    • Control: running inspect-web-page while the connect-mode scenario re-navigated its start_url failed with target_unavailable / target_changed, so passive and driven capture should not overlap on one target.
    • Unknown: connect-mode completeness was incomplete (missing_sections: ["events"], "CDP attachment cannot recover pre-attach events...") on both browsers. No changed-variant compare-web-captures run in this record.
  • Estimated cost; measured time, CPU/RSS, temporary/output space: not measured. Each scenario output was about 100 KB of JSON with response bodies selected.
  • Lifecycle and cleanup result: browser.cleanup: disconnected-external, and the external browser stayed alive after each capture. I then stopped both browsers and the server and deleted the temp profiles.
  • Verification command / report: manual CLI runs above; npm run verify:browser not run for this record.
  • Script, recording, documentation and PR links: no recording. Related skill-routing PR: #2286.
  • Blocker or next action: measure time/RSS; repeat on Linux; add a changed variant with compare-web-captures in connect mode.
<!-- gh-comment-id:6130041226 --> @0xRafie commented on GitHub (Oct 12, 2026): Verification record for D03 (browser behavior): notes-web demo on two Chromium-family browsers, using the scenario block from this issue. #### D03 — notes-web Export notes, connect mode on Chrome and Brave - Status / owner: Verified on one host (macOS); not recorded. - Analyst question / expected answer: What does "Export notes" do? It fetches `notes.json` (200), builds a CSV in the page, and the status reads "Exported 2 notes to notes.csv.". - Why select it / coverage added: the D03 record in PR #1704 uses launch mode with Chrome 154. This adds a connect-mode variant (an existing loopback browser) and a second Chromium-family browser (Brave). - Target source, license, digest and generation procedure: `website/public/examples/notes-web/` from main `d96550f`, served with `python3 -m http.server --bind 127.0.0.1 8791` from `website/public`. `export.js` sha256 `66f5c2501bfca72eb743a1fffbdce9a58d295e69ca66f19562e9b0fa9fc189a6` (925 bytes). REA's captured source digest matches the file. - Public REA operations / CLI recipe: ``` "<browser executable>" --headless=new --use-mock-keychain --no-first-run --no-default-browser-check \ --user-data-dir="$(mktemp -d)" --remote-debugging-port=<port> http://127.0.0.1:8791/examples/notes-web/ rea list-browser-targets http://127.0.0.1:<port> rea capture-browser-scenario scenario.json rea inspect-web-event-listeners http://127.0.0.1:<port> <target_id> '#export' ``` scenario.json: ```json {"browser":{"mode":"connect","cdp_endpoint":"http://127.0.0.1:<port>","target_id":"<target_id>"}, "start_url":{"url":"http://127.0.0.1:8791/examples/notes-web/"}, "actions":[{"step_id":"export","action":"click","locator":{"kind":"css","selector":"#export"},"timeout_ms":10000}, {"step_id":"wait","action":"wait_for_timeout","duration_ms":500}], "capture":{"events":["network"],"network":{"response_body":true},"at_end":["dom","url"]}} ``` - Host, REA artifact and provider prerequisites: macOS 26.7.1 (25G241); REA 6.4.0 built from main `d96550f` (`node scripts/rea.mjs`); Node 26.9.0. Browsers: Google Chrome 154.0.8037.99 and Brave Browser 155.1.97.56 (Chromium 155.0.8059.40), both headless. - Independent oracle / meaningful unknown or control: - Scenario, both browsers: steps `scenario_start`, `export`, `wait` completed. In the `export` step: `GET http://127.0.0.1:8791/examples/notes-web/notes.json`, resource_type `fetch`, response status `200`. The final DOM status reads "Exported 2 notes to notes.csv." and matches the handler in `export.js`. - Listeners, both browsers: one `click` listener on `#export` at `export.js` line 0, column 60 (`source_association: script_id`). - Initiator: scenario events carry none (limitation: "Playwright scenario events do not expose request initiator stacks"). A passive `inspect-web-page` (4 s window) while the button was clicked through a separate CDP `Runtime.evaluate` reported `notes.json` GET Fetch 200 with initiator `{type: script, url: .../notes-web/export.js, line: 3, column: 27}` (Chrome only). - Control: running `inspect-web-page` while the connect-mode scenario re-navigated its `start_url` failed with `target_unavailable` / `target_changed`, so passive and driven capture should not overlap on one target. - Unknown: connect-mode `completeness` was `incomplete` (`missing_sections: ["events"]`, "CDP attachment cannot recover pre-attach events...") on both browsers. No changed-variant `compare-web-captures` run in this record. - Estimated cost; measured time, CPU/RSS, temporary/output space: not measured. Each scenario output was about 100 KB of JSON with response bodies selected. - Lifecycle and cleanup result: `browser.cleanup: disconnected-external`, and the external browser stayed alive after each capture. I then stopped both browsers and the server and deleted the temp profiles. - Verification command / report: manual CLI runs above; `npm run verify:browser` not run for this record. - Script, recording, documentation and PR links: no recording. Related skill-routing PR: #2286. - Blocker or next action: measure time/RSS; repeat on Linux; add a changed variant with `compare-web-captures` in connect mode.
bsakaguchi commented 2026-10-17 21:01:18 +00:00
Author
Owner
Copy link

@pablodiazjorge commented on GitHub (Oct 15, 2026):

Native Windows walkthroughs, in case they help the index: rea-lab keeps reproducible writeups run with rea 6.4.0 and real Ghidra 12.1.4 on Windows 11, each with its scripted session and sanitized, re-authenticated Evidence: WinHelloCPP (the Ghidra sample), Wallace v1 against v2 with compare_functions, and a seeded crackme at -O0 and -O2. They live outside the REA repository, so they fit as external references rather than numbered demos.

<!-- gh-comment-id:6193465541 --> @pablodiazjorge commented on GitHub (Oct 15, 2026): Native Windows walkthroughs, in case they help the index: [rea-lab](https://github.com/pablodiazjorge/rea-lab) keeps reproducible writeups run with rea 6.4.0 and real Ghidra 12.1.4 on Windows 11, each with its scripted session and sanitized, re-authenticated Evidence: [WinHelloCPP](https://github.com/pablodiazjorge/rea-lab/tree/main/writeups/2026-10-winhellocpp) (the Ghidra sample), [Wallace v1 against v2](https://github.com/pablodiazjorge/rea-lab/tree/main/writeups/2026-10-wallace-versions) with `compare_functions`, and [a seeded crackme at -O0 and -O2](https://github.com/pablodiazjorge/rea-lab/tree/main/writeups/2026-10-own-xor). They live outside the REA repository, so they fit as external references rather than numbered demos.
bsakaguchi commented 2026-10-17 21:01:19 +00:00
Author
Owner
Copy link

@TheDesignFounder commented on GitHub (Oct 16, 2026):

I've opened a draft walkthrough
for a small game example that could fit this collection: does moving diagonally make the player faster?

In Relay garden,
we used REA to locate the movement function in a small JavaScript reference we
wrote. Reading that function showed that full diagonal and straight input cover
the same distance, away from the edges of the game world. A separate
implementation matched the reference across 2,000 test inputs.

The proposed walkthrough includes the command-line steps, recorded MCP requests
and responses, and instructions for repeating the checks. It also explains where
REA's analysis was incomplete, including a search that missed a number present
in the code.

There are two videos: a 30-second gameplay clip
and a separate guided recording of the investigation. The investigation recording follows a prepared
sequence using real REA calls and test results. We knew the reference code
beforehand.

Play the game ·
Read the article

We added original artwork using Dreamlayer. This would add one example to the
work in #1704 and leave the broader goals of #778 open.

Would this be a useful addition?

<!-- gh-comment-id:6223361847 --> @TheDesignFounder commented on GitHub (Oct 16, 2026): I've opened [a draft walkthrough](https://github.com/morluto/rea/pull/4567) for a small game example that could fit this collection: **does moving diagonally make the player faster?** In [Relay garden](https://github.com/TheDesignFounder/dreamlayer-game-assets), we used REA to locate the movement function in a small JavaScript reference we wrote. Reading that function showed that full diagonal and straight input cover the same distance, away from the edges of the game world. A separate implementation matched the reference across 2,000 test inputs. The proposed walkthrough includes the command-line steps, recorded MCP requests and responses, and instructions for repeating the checks. It also explains where REA's analysis was incomplete, including a search that missed a number present in the code. There are two videos: a [30-second gameplay clip](https://github.com/user-attachments/assets/155db219-8f74-47af-9079-94cac8a6d77e) and a separate [guided recording of the investigation](https://github.com/user-attachments/assets/6a79bb7e-a246-4a77-b272-339116e5dd93). The investigation recording follows a prepared sequence using real REA calls and test results. We knew the reference code beforehand. [Play the game](https://thedesignfounder.github.io/dreamlayer-game-assets/demo/) · [Read the article](https://dreamlayer.io/blog/rea-game-assets) We added original artwork using Dreamlayer. This would add one example to the work in #1704 and leave the broader goals of #778 open. Would this be a useful addition?
bsakaguchi commented 2026-10-31 00:29:04 +00:00
Author
Owner
Copy link

@ylwl1997 commented on GitHub (Oct 19, 2026):

Follow-up scenario candidate (community / unofficial)

Thanks for maintaining this demo-portfolio tracker — the D01–D12 matrix is a clear way to schedule reproducible walkthroughs.

Suggestion: consider a Follow-up row (adjacent to D06 Android APK) for own Android TV / ADB-authorized device ops + optional APK inspect:

Piece Sketch
Analyst question On a TV I own, after I enable developer options and approve the debugging prompt on the set, which preinstall packages can I inventory/disable with public adb/pm disable-user, and what does a chosen open-source sideload APK declare before install?
REA contribution Optional inspect_android_package (and related Android tools) on an APK the operator already chose; device lane stays on an authorized adb devices session (human gate). Main ops path can be agent + platform-tools ADB.
Fixture / boundary Own/authorized Android TV–class device only; no DRM/paid-stream cracks; “ads” = disable preinstall ad/bloat packages, not ad-SDK/DRM bypass; sideload clearly open-source clients (e.g. Jellyfin Android TV) — not gray aggregators.

Community teaching write-up (independent / not affiliated with REA maintainers; not a claim that this is an official demo entry):

Related site notes: https://rea.run/docs/android-adb/ · https://rea.run/compliance/ · https://rea.run/faq/legal-boundary/

Happy to adjust wording if maintainers prefer this stays outside the formal matrix until a shareable fixture + recording exist. Official source of truth remains https://github.com/morluto/rea.

<!-- gh-comment-id:6257455670 --> @ylwl1997 commented on GitHub (Oct 19, 2026): ### Follow-up scenario candidate (community / unofficial) Thanks for maintaining this demo-portfolio tracker — the D01–D12 matrix is a clear way to schedule reproducible walkthroughs. **Suggestion:** consider a **Follow-up** row (adjacent to **D06 Android APK**) for *own Android TV / ADB-authorized device ops + optional APK inspect*: | Piece | Sketch | | --- | --- | | Analyst question | On a TV **I own**, after I enable developer options and approve the debugging prompt on the set, which preinstall packages can I inventory/disable with public `adb`/`pm disable-user`, and what does a chosen open-source sideload APK declare before install? | | REA contribution | Optional `inspect_android_package` (and related Android tools) on an APK the operator already chose; device lane stays on an **authorized** `adb devices` session (human gate). Main ops path can be agent + platform-tools ADB. | | Fixture / boundary | Own/authorized Android TV–class device only; no DRM/paid-stream cracks; “ads” = disable preinstall ad/bloat packages, not ad-SDK/DRM bypass; sideload clearly open-source clients (e.g. Jellyfin Android TV) — not gray aggregators. | Community teaching write-up (independent / **not affiliated** with REA maintainers; not a claim that this is an official demo entry): - https://rea.run/showcase/android-tv-adb-rea-ops/ Related site notes: https://rea.run/docs/android-adb/ · https://rea.run/compliance/ · https://rea.run/faq/legal-boundary/ Happy to adjust wording if maintainers prefer this stays outside the formal matrix until a shareable fixture + recording exist. Official source of truth remains https://github.com/morluto/rea.
bsakaguchi commented 2026-10-31 00:29:04 +00:00
Author
Owner
Copy link

@8rulerstar commented on GitHub (Oct 21, 2026):

A possible IL2CPP scenario, in case it fits the tracker. Location and format are entirely up to you.

Dxx (Unity IL2CPP): which assembly and type declare a game script's methods, and where is their native code?

  • Status / owner: verified on one host (macOS 27.0.1 arm64); not recorded. Branch docs/unity-il2cpp-demo, based on main d0067ba34; not a PR.
  • Analyst question / expected answer: which image and type declare Sample.Player.Update, what do it and its nested type declare, and which native address does the build link Update to? Answer: Assembly-CSharp.dll (image 35) declares Sample.Player (type 2459) with Update, .ctor and field slot; nested Slot (2458) declares Add, .ctor and field Count; Add has no parameters. With the arm64 slice of GameAssembly.dylib, Update (method 12477) links to 0x153560, state code.
  • Coverage added: D05 lists IL2CPP decoding as outside the managed parser; the merged inspect_il2cpp_metadata (#3807, #5326, #5327) covers the metadata and its native address links.
  • Target: a self-authored three-file Unity 2022.3.62f3 project, sources inline. Build outputs are not committed. Three builds gave identical metadata (1,912,344 bytes, SHA-256 2875f161ae0da99b83932b52aace567747070a45af9d696bc52a725a58c358b7, version 31) but three different GameAssembly.dylib digests at the same size; the walkthrough records the one used.
  • Operations: inspect-il2cpp-metadata --detail summary --evidence_output, inspect-analysis-view over images, types, methods, fields, parameters (method_indices) and method_addresses, and --binary --architecture arm64 --ghidra-seeds. MCP parity was measured on an earlier build (c374c2fe7) and not rerun.
  • Oracle / control: the C# source for names and ownership; CiBuild (editor-only) returns no rows. No independent oracle for the addresses.
  • Measured (single runs, host under other load): Unity build 77 s, 1.7 GB RSS; npm run verify:il2cpp:metadata passed in 10.0 s; the --binary decode 1.3 s, 498 MB, 11,022 seeds. Token cost unmeasured.
  • Not done: analyze_function on 0x153560 is unmeasured, because the local Ghidra 12.1.4 has no macOS arm64 native decompiler and open_binary rejected the provider.

Thank you for your time.

<!-- gh-comment-id:6304966295 --> @8rulerstar commented on GitHub (Oct 21, 2026): A possible IL2CPP scenario, in case it fits the tracker. Location and format are entirely up to you. #### Dxx (Unity IL2CPP): which assembly and type declare a game script's methods, and where is their native code? - Status / owner: verified on one host (macOS 27.0.1 arm64); not recorded. Branch [`docs/unity-il2cpp-demo`](https://github.com/8rulerstar/rea/tree/docs/unity-il2cpp-demo), based on main `d0067ba34`; not a PR. - Analyst question / expected answer: which image and type declare `Sample.Player.Update`, what do it and its nested type declare, and which native address does the build link `Update` to? Answer: `Assembly-CSharp.dll` (image 35) declares `Sample.Player` (type 2459) with `Update`, `.ctor` and field `slot`; nested `Slot` (2458) declares `Add`, `.ctor` and field `Count`; `Add` has no parameters. With the arm64 slice of `GameAssembly.dylib`, `Update` (method 12477) links to `0x153560`, state `code`. - Coverage added: D05 lists IL2CPP decoding as outside the managed parser; the merged `inspect_il2cpp_metadata` (#3807, #5326, #5327) covers the metadata and its native address links. - Target: a self-authored three-file Unity 2022.3.62f3 project, sources inline. Build outputs are not committed. Three builds gave identical metadata (1,912,344 bytes, SHA-256 `2875f161ae0da99b83932b52aace567747070a45af9d696bc52a725a58c358b7`, version 31) but three different `GameAssembly.dylib` digests at the same size; the walkthrough records the one used. - Operations: `inspect-il2cpp-metadata --detail summary --evidence_output`, `inspect-analysis-view` over images, types, methods, fields, parameters (`method_indices`) and `method_addresses`, and `--binary --architecture arm64 --ghidra-seeds`. MCP parity was measured on an earlier build (`c374c2fe7`) and not rerun. - Oracle / control: the C# source for names and ownership; `CiBuild` (editor-only) returns no rows. No independent oracle for the addresses. - Measured (single runs, host under other load): Unity build 77 s, 1.7 GB RSS; `npm run verify:il2cpp:metadata` passed in 10.0 s; the `--binary` decode 1.3 s, 498 MB, 11,022 seeds. Token cost unmeasured. - Not done: `analyze_function` on `0x153560` is unmeasured, because the local Ghidra 12.1.4 has no macOS arm64 native decompiler and `open_binary` rejected the provider. Thank you for your time.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
codex/procedure-reference-stacked
release-please--branches--main--components--rea-agents
release-please--branches--main--components--rea-agents--release-notes
codex/kuna-independent-retry
codex/byte-search-overlay-coverage
codex/open-failure-target-receipt
codex/kuna-xref-evidence
codex/ghidra-ambiguous-procedure-recovery
codex/function-source-bundle
codex/trace-function-integration-prototype
codex/snapshot-source-closure
codex/recorded-evidence-array-pages
codex/evidence-recovery-redesign
codex/trace-feature-address-scope
codex/call-discovery-scope
codex/ghidra-literal-candidate-evidence
codex/decompile-directory-independent-retry
codex/retry-provenance-base
codex/value-flow-capability-experiment
codex/ghidra-containing-instruction
cursor/readme-discord-button-ef9f
dependabot/github_actions/actions/setup-node-7.1.0
dependabot/github_actions/actions/upload-artifact-7.0.2
dependabot/npm_and_yarn/npm-minor-and-patch-d8d97ce6df
codex/kuna-1989
fix/8559-native-ui-fixture-ownership
fix/8555-go-verifier-mcp-ownership
codex/provider-capability-recovery
fix/8642-rizin-target-stdin
codex/ghidra-memory-effect-scope
codex/ghidra-annotation-entry-selector
codex/ghidra-readonly-recovery
codex/ghidra-regex-verifier-recovery
codex/evidence-discovery-view-guidance
fix/8545-bulk-append-overflow
fix/8428-navigation-refusal-alternatives
codex/address-context-recovery
codex/matching-member-limitations
codex/unknown-scope-contract
codex/evidence-view-guidance
feat/8373-native-trace-views
codex/ghidra-snapshot-verifier-binding
codex/elf-export-visibility
codex/evidence-view-recovery
codex/native-reference-cli-help
codex/provider-candidate-observation-scope
codex/kuna-session-verification
codex/ghidra-switch-lifetime-guidance
codex/pseudocode-paging-discovery
codex/clarify-evidence-view-support
codex/kuna-xrefs-selector-recovery
codex/context-capacity-recovery
codex/evidence-closure-large-links
codex/same-function-evidence-identity
codex/ghidra-verifier-inspected-jdk
codex/audit-guided-workflows
codex/crash-prompt-retained-dossiers
codex/analysis-view-error-recovery
codex/kuna-verifier-target-selection
codex/ghidra-selected-project-call-coverage
codex/docs-native-analysis-scope
codex/ghidra-java-socket-boundary
codex/ghidra-retained-snapshot-verifier
codex/ghidra-search-inventory-facts
fix/8284-zero-argument-parameter-bindings
fix/8198-ui-action-handler-offset
fix/8257-elf-entry-label-identity
fix/8304-deferred-output-schema-projection
fix/8277-call-path-computed-target-uncertainty
fix/pr-8089-conflicts
fix/ci-static-duplicate-export
dependabot/npm_and_yarn/lint-staged-17.6.0
dependabot/github_actions/actions/download-artifact-8.0.2
dependabot/npm_and_yarn/write-file-atomic-8.0.0
dependabot/npm_and_yarn/canonicalize-5.1.0
dependabot/github_actions/actions/cache/restore-6.1.0
dependabot/npm_and_yarn/toon-format/toon-4.4.0
dependabot/github_actions/actions/deploy-pages-5.0.1
codex/review-fixes-pr-2403
codex/review-fixes-pr-2400
codex/process-terminal-width
codex/test-brittleness-cleanup
verify/7167-browser-connect-macos
fix/7167-browser-connect
feat/native-matching-allowance-setting
feat/browser-scenario-dry-run
test/managed-caller-parameters-20261024
codex/parser-fortythird-boundaries
fix/6926-pinvoke-platform-decorations-20261023
fix/6889-har-body-encoding-20261023
fix/6888-sqlite-schema-budget-20261023
fix/dependency-security-gates-6708
cursor/evidence-overwrite-rebase-b4ac
feat/4057-verify-native-exports
fix/windows-acl-observer-overhead-20261022
cursor/erlang-beam-restack-4476
cursor/pe-certificate-review-bf32
fix/6116-javascript-application-fs-errors
fix/6061-unmapped-runtime-script-unknown
feat/browser-scenario-summary
fix/pe-certificates
codex/verify-3407
cursor/rebase-5699
cursor/rebase-5352
cursor/rebase-5600
cursor/fix-cli-schema-omission-10a8
codex/audit-hopper-shutdown-reasons-20261021
fix/demangle-swift-omitted-record
fix/nib-boolean-value-types
cursor/cancellation-partial-observation-a5ac
fix/ib-object-limit-reasons
fix/electron-fuse-limit-advice
fix/kuna-doctor-dangling-cache
fix/fixed-budget-refusal-advice
fix/js-ipc-listener-dedup
fix/js-return-member-provenance
fix/dmg-integrity-retry-advice
fix/ida-doctor-readiness
fix/kuna-version-probe-output-drain
fix/legacy-swift-runtime-name-matching
fix/dylib-lazy-load-commands
fix/browser-scenario-startup-cancel
fix/swift-nested-punycode-classification
fix/compare-unselected-scopes
fix/objc-method-budget-coverage
fix/dmg-mounted-root-observations
audit/ci-tests-20261019-round2
release/6.7.0
fix/wabt-cleanup-retry-resolution
fix/electron-fuse-elf-pe-architecture
fix/native-plist-descriptor-ownership
fix/kuna-caller-cleanup-ownership
experiment/atomic-codemode-20261016
review/first-contributor-3776
fix/call-resolution-full-read-cycles
fix/member-mutation-selection-repeat
experiment/atomic-re-tools-20261015
perf/member-mutation-lazy-origins
perf/static-network-mutation-index
fix/hopper-startup-lifecycle
audit/3050-windows-proof-20261015
feat/windows-window-capture-2183
audit/3049-windows-proof-20261015
audit/3735-macos-fixtures-20261015
fix/batch-decompile-null-pseudocode
fix/kuna-inventory-honors-jobs
experiment/browser-codemode-tool-design-20261015
fix/hopper-clean-runtime-argv
codex/review-2049-27f1b367
review-fixes/pr-2787-routing
fix/3360-scoped-this-emitters
fix/3367-replaced-global-effects
fix/3838-compact-any-value-items
test/hopper-download-probe-20261015
codex/windows-runtime-creation-red-green-20261015
codex/windows-readonly-root-red-green-20261015
codex/windows-root-share-red-green-20261015
codex/exp-1685-win-mcp-startup
codex/bug-sweep-20261015
investigate/2190-windows-package-phases
investigate/3543-macos-cli-deadline
perf/3281-reverse-tools-feedback-quality
fix/3406-hopper-doctor-fixture
fix/3341-wrapper-require-test-context
fix/3301-owned-uninstall-fixtures
fix/3164-compiler-input-ownership
fix/pcap-cleanup-stdout-newline-20261014
perf/interface-builder-summary
codex/review-fixes-pr-1977
fix/ghidra-effective-jvm-platform
fix/docs-turkish-rust-link-20261013
fix/main-maintenance-ci-20261010
fix/recover-binary-session-process-effects
codex/review-fixes-pr-2457
codex/ci-required-cancellation-gate
fix/main-format-baseline-20261013
fix/setup-preserve-entry-fields
cursor/restore-main-checks-1ffc
fix/ghidra-bridge-hashmap-import
codex/shared-ci-jadx-json-default-20261013
codex/shared-ci-ghidra-test-groups-20261013
codex/shared-ci-java-fixture-format-20261013
codex/fix-intrinsic-invocation-boundaries
test/release-preflight-reusable-jobs
test/js-parameter-provenance-expectation
fix/linux-hopper-verification-current
test/2419-ghidra-elf-probe-size
followup/pr-1544-native-ida
codex/fold-pr-2230-contribution
docs/readme-responsible-use
fix/issue-2064
fix/issue-2050
fix/issue-2053
fix/issue-1968
fix/issue-1945
experiment/codemode-bridge-20261011
fix/tool-effects-negative-wording-1904-20261012
fix/1842-electron-interop-provenance
feat/recover-javascript-multi-input
refactor/website-i18n-prep
fix/nativeaot-pe-virtual-extent
fix/browser-verifier-ci-hang
fix/pe-resources-input-selection
docs/beginner-friendly-guides
docs/beginner-setup-guide
fix/javascript-analysis-worker-1563
fix/1649-ghidra-duplicate-names
fix/javascript-export-keys-integration-1369
test/maintenance-boundary-contracts-20261011
review/javascript-export-keys-1369
review/process-live-progress-1483
test/javascript-1495-growth-ratio
fix/ci-escape-timing
docs/normalized-terminal-geometry-1450
release/6.3.0
archive/release-6.3.0-pr1381
release/6.2.0
fix/electron-preload-dynamic-override
fix/javascript-self-referential-bundler-edges
release/6.1.0
cursor/grok-client-cherry-pick-0b56
feat/signature-posture
feat/dyld-shared-cache
feat/artifact-integrity-policy
feat/pkg-inventory
release/6.0.0
chore/sync-release-5.0.0
release/5.0.0
cursor/cloud-agent-node-787e
fix/javascript-xhr-open-endpoints
review/pr-711-realpath-fallback-wording
cleanup/replay-confinement
codex/test-suite-performance
codex/issue-foundations
codex/address-open-issues-2026-07-20
agent/javascript-vite-rollup-esbuild-adapters
agent/process-cleanup
agent/triage-integration
agent/unknown-commands-registry
feat/mcp-identity-metadata
morlvps/issue_cleanup
codex/installer-redesign
morl/roadmap-investigation-core
morl/roadmap-investigation-docs
release-please--branches--main--components--rea
rea-agents-6.8.0
rea-agents-6.7.0
rea-agents-6.6.0
experiment/atomic-codemode-wait-runtime-20261016
rea-agents-6.5.0
rea-agents-6.4.0
rea-agents-6.3.0
rea-agents-6.2.0
rea-agents-6.1.0
rea-agents-6.0.0
rea-agents-5.0.0
rea-agents-4.1.0
rea-agents-4.0.1
rea-agents-4.0.0
rea-agents-3.2.1
rea-agents-3.2.0
rea-agents-3.1.0
rea-agents-3.0.0
rea-agents-2.7.0
rea-agents-2.6.0
rea-agents-2.5.1
rea-agents-2.5.0
rea-agents-2.4.0
rea-agents-2.3.0
rea-agents-2.2.0
rea-agents-2.1.0
rea-agents-2.0.0
rea-agents-1.7.0
rea-agents-1.6.0
rea-agents-1.5.0
rea-agents-1.4.0
rea-agents-1.3.0
rea-agents-1.2.0
rea-agents-1.1.0
rea-agents-1.0.0
rea-agents-0.5.0
rea-agents-0.4.0
rea-agents-0.3.0
rea-0.2.1
rea-0.2.0
Labels
Clear labels   
area: bridge

   
area: bridge

   
area: build

   
area: build

   
area: build

   
area: cli

   
area: domain

   
area: evidence

   
area: mcp

   
area: native

   
area: providers

   
area: runtime

   
area: server

   
area: setup

   
area: tests

   
bug

   
design

   
documentation

   
enhancement

   
enhancement

   
enhancement

   
experiment

   
help wanted

   
i18n

   
invalid

   
P0: critical

   
P1: high

   
P2: medium

   
P2: medium

   
P2: medium

   
P3: low

   
performance

   
provider-request

   
pull-request
Mirrored from GitHub Pull Request

  
question

   
roadmap

   
triage
No labels
area: bridge
area: bridge
area: build
area: build
area: build
area: cli
area: domain
area: evidence
area: mcp
area: native
area: providers
area: runtime
area: server
area: setup
area: tests
bug
design
documentation
enhancement
enhancement
enhancement
experiment
help wanted
i18n
invalid
P0: critical
P1: high
P2: medium
P2: medium
P2: medium
P3: low
performance
provider-request
pull-request
question
roadmap
triage
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#337
No description provided.