REA welcomes focused bug fixes, documentation improvements, tests, and reverse-engineering workflows. For large contract or architecture changes, explain the intended scope and link the relevant issue or design discussion.
Explain the concrete problem, keep related corrections together, and report verification and unavailable coverage. Contributions should justify their review and maintenance cost. Keep cosmetic polish with useful fixes; confusing or incorrect user instructions warrant standalone corrections. Collect other cosmetic-only suggestions in an issue rather than separate PRs.
For capability organization and provider composition, use the
architecture map. Production factories in
src/composition/ construct fresh providers without starting engines or acquiring
targets; optional adapter failures must preserve successful peers. Run
npm run verify:test-discovery after adding or moving tests. Resolved import
boundaries are checked by npm run verify:module-boundaries, included in lint.
For analysis workflows and agent interfaces, follow the performance priorities. Explain the selected output scope, reuse/cache decisions, and relevant before/after measurements when these costs change.
When adding or changing an MCP tool, follow the tool design guide and preserve the canonical contracts and generated catalog.
REA focuses on software structure, runtime behavior, and evidence through general-purpose reverse-engineering workflows. Evaluate a proposal by its actual capabilities, side effects, defaults, and complete workflow. A tool name or a reference to vulnerability research, malware analysis, or CTFs does not determine whether it belongs in REA.
Supported contributions include format inspection, ordinary archive and standard compression extraction, disassembly, decompilation, cross-references, general static deobfuscation, vulnerability analysis, and evidence reporting. Static protection detection is distinct from defeating that protection. Security fixes and isolated regression tests remain in scope.
Runtime investigation needs explicit boundaries. Launching or attaching to a process, injecting instrumentation, running scripts, and changing memory or registers require review of target selection, execution and mutation authority, provenance, resource limits, cancellation, and cleanup. General Frida or debugger support is not inherently read-only, and existing support does not authorize every workflow built on it. General-purpose interfaces are not classified as dedicated bypass workflows solely because caller-provided code could be misused; their execution and mutation authority must still be reviewed.
REA does not integrate or officially distribute:
- Purpose-built workflows to defeat commercial packing or code-virtualization protections and automatically recover protected code.
- Anti-debugging or anti-instrumentation evasion, or DRM, license, anti-cheat, or access-control bypass workflows.
- Exploit or attack-payload automation, credential theft, covert persistence, unauthorized access, or bulk attack workflows.
These boundaries apply to first-party providers, adapters, plugins, bundled scripts, defaults, examples, and documentation. Moving a capability into an optional dependency or plugin does not exempt it. Review what the integration exposes, including upstream defaults and raw-command or script execution paths. Ordinary extraction and general static deobfuscation are not excluded merely because the input is packed or obfuscated; assess added bypass or execution behavior separately.
This is a product and maintenance boundary, not a judgment about a contributor's intentions or a declaration that all excluded research is unlawful. Contributors must have the rights and authorization needed for their work. A local-only design or an "authorized use only" disclaimer does not establish containment or settle legal and scope questions.
If scope fit, target or authorization boundaries, side effects, or the verification needed to establish those boundaries remain materially unresolved, do not merge, enable, or include the capability in official packages or distributions. Keep the proposal pending, narrow it, or decline it. Record unknowns explicitly; do not turn them into "none" or assumed safety. Passing CI, completed implementation, upstream popularity, or silence from maintainers is not scope approval.
For a new provider or a capability involving target execution, injection, mutation, or protection recovery, seek an explicit maintainer scope decision in the linked issue or design discussion before substantial implementation intended for integration. Small exploratory prototypes and draft PRs may help inform that decision; they do not authorize integration. The decision must cover the final proposed behavior; a scope expansion needs a new decision. Routine fixes and documentation changes within existing boundaries do not need a separate advance decision, but must not silently expand those boundaries.
To open a feature request or design discussion, describe the problem and desired outcome or decision. Short answers and the forms' "Not sure yet" options are welcome. You do not need code, a complete design or test plan, legal analysis, or private proof-of-authorization documents to start a discussion. Share what you know and leave optional details blank when you need help.
Form selections guide triage; they are not proof of authorization or scope approval. Unselected effects must not be treated as established absence. Maintainers and implementers work together to resolve the following before integration:
- The concrete analyst question, requested inputs and outputs, and why existing REA operations are insufficient.
- Why the workflow fits this scope, its non-goals, and any protection recovery, bypass, or attack automation it would expose.
- The selected targets and every execution, injection, mutation, network, or persistence effect, including behavior inherited from upstream tools.
- How the boundaries and outcome will be verified with self-owned or appropriately licensed samples; identify real CLI/MCP and provider coverage, cleanup and resource checks, and remaining unknowns. Do not publish private binaries, credentials, or sensitive target data; follow SECURITY.md for private vulnerability reports.
Mixed proposals should separate acceptable analysis capabilities from excluded workflows so each can be decided independently. An issue may discuss unresolved questions; opening an issue or PR does not authorize integration. This is a maintainer integration gate, not a per-call confirmation requirement or a sandbox guarantee.
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.
npm ci
npm run check:fastnpm ci installs the exact dependencies and prepares the Husky hooks without
building the project. Run npm run build:cached when you need the standalone
CLI or MCP server; it compiles the runtime and bundles the authored skill.
npm run build forces those tasks to rerun. Neither command generates test
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.
Repository invariants live in AGENTS.md. Keep provider-specific protocols in adapters and shared CLI/MCP workflows in the application layer.
The VitePress site uses the Markdown files in docs/. Run npm run docs:dev
for live editing, npm run docs:build to check the production build and
links, and npm run docs:preview to preview that build at /rea/.
Site navigation lives in docs/.vitepress/config.ts. Keep links to guides
relative so they work on GitHub and the website; link to repository files
outside docs/ using their full GitHub URLs. Generated reference documents
use npm run docs:generate; docs:build generates them before building the website.
Pull requests run npm run docs:check. .github/workflows/pages.yml is a
manual VitePress build and does not publish. The public site at
https://rea.tools/ serves website/public/ through Cloudflare Workers. See
the website README for previews and
manual deployments.
The separate GitHub Pages host uses only the manual
.github/workflows/website-pages.yml workflow on main. The repository's
Settings → Pages → Build and deployment → Source must be set to
GitHub Actions before deploying there.
Select checks for the behavior changed. For a source edit:
npm run test:focused -- src/config.test.ts
npm run check:fasttest:local runs source tests without building. check:changed combines cached
static checks with source tests affected since the merge base with origin/main.
Import-graph selection can miss runtime registration, bridges, and generated data;
select relevant boundary tests explicitly. See testing
for commands, test placement, pruning, and real-provider prerequisites.
Before requesting review, run relevant tests and npm run check; add
npm run docs:check when contracts or generated metadata change. Record the
checks and unavailable coverage. CI owns the full deterministic suite and
coverage. npm run check:pr is an optional full local gate for broad changes or
CI diagnosis. Packaging/setup/distribution changes additionally require
npm run verify:package and npm pack --dry-run; provider changes require the
matching real-provider lane. State which host/provider workflows ran.
check:pr reuses build and static-check outputs while executing the test suite
fresh, including the fast Python producer checks. docs:check also runs the
onboarding example consistency suite for README-only changes.
Pre-commit formats and lints staged files; pre-push runs check:fast.
docs:generate prepares documentation and portable managed evidence;
evidence:generate prepares only the managed commitment and its runtime/skill
dependencies. The ignored outputs are docs/public/product-catalog.json,
docs/verification/managed-conformance-*.json, and skills/. Edit authored
skill instructions in .agents/skills/reverse-engineer-anything/, where Skills
can discover the public bundle directly from a clean checkout. verify:package
installs that bundle with Skills 1.7.2 using default repository-root discovery
and checks every installed file, alongside the packaged setup checks.
CI validates generated outputs and retains them as artifacts; do not commit
them. Reviewed source metadata, including
src/generatedPackageMetadata.ts and docs/error-contract.schema.json, remains
tracked and checked for freshness.
The packaged skill contains instructions and inventory metadata, not runtime
schema hashes. Its conformance commitment covers that exact bundle and portable
verification; it does not attest optional real-provider runs. Schema-only changes
should not alter that commitment. Doctor and binary_session expose runtime
schema identity.
Build/generation commands hold a SQLite transaction around the entire Turbo
graph, including cache restoration. .cache/rea-command-locks/ databases identify
locks, not stale files; never remove them while commands run. POSIX cancellation
retains process-group ownership until settlement; Windows waits for completion.
Real-provider execution is uncached.
Tests use createTestTempDirectory from tests/fixtures/temporaryDirectory.ts
for exact-path, awaited cleanup, including failures and timeouts.
npm run verify:test-temp-hygiene runs the suite under a fresh TMPDIR and
rejects remaining REA-owned paths. Never glob-clean shared /tmp/rea-* content.
REA_LOG_LEVEL selects trace, debug, info, warn, error, fatal, or
silent. Logs go to stderr: MCP defaults to info, and one-shot CLI logging
is opt-in, so stdout carries only protocol messages and command results.
Request arguments, bridge tokens, and environment data are redacted from
diagnostic logs.
Run npm run verify:hopper on a supported macOS host or
npm run verify:hopper:linux on the supported Linux demo runner. These build
native fixtures and verify the installed engine through CLI/MCP; package or
simulated-provider checks do not establish engine behavior. See
real-toolchain verification
for prerequisites and scope, and Hopper setup
for supported hosts and unattended startup.
Use the default build/conformance/manifest.json unless explicitly verifying
another source-built manifest with REA_HOPPER_CONFORMANCE_MANIFEST_PATH.
Generated fixtures and manifests remain ignored.
Use the release guide. Main pushes automatically refresh a Release Please PR with the next version and changelog. Review its migration notes, wait for the current CI checks to pass, and merge it into main to publish.
The Release workflow validates and tags that merge; both publishers build its
exact SHA. Ordinary main pushes cannot publish packages. An optional manual
release/VERSION checkpoint retains explicit preparation and publication.
For grouped release notes with verified contributor thanks, use the repository's
rea-changelog-update skill in .agents/skills/rea-changelog-update/. Its inventory,
credit checks, and finalization process are described in the release guide.
Keep new implementation commits on main for the next release. The workflow owns packaged-artifact verification, npm publication, the published CLI/MCP canary, and MCP Registry publication. Sync manual checkpoint metadata back to main after publication; see the guide for recovery and verification.