REAFUSE

Operating manual / clean-room fusion lab

How the fuse
actually works.

ReaFuse studies what two software donors do, proposes a useful hybrid, writes fresh code against tests, and shows its work from intake to verdict.

Documentation circuit online

Quick start

On the home page, enter two app names, public URLs or GitHub repositories. ReaFuse resolves both donors, inspects their observable capabilities, and offers three possible fusions.

  1. Connect donor A and donor B.
  2. Start the fuse and wait for the three concepts.
  3. Choose the creature worth building.
  4. Watch contract tests, generation and verification happen live.
  5. Inspect the verdict, lineage, files and working preview when available.
Good inputChoose two products with distinct strengths. “Duolingo × Tinder” gives the lab more useful tension than two nearly identical note apps.

The pipeline

Every run follows the same visible sequence. A stage may retry or stop when the evidence, model provider or generated tests are not strong enough.

  1. 01 / RESOLVEFind donors
  2. 02 / DISSECTMap behavior
  3. 03 / FUSEChoose concept
  4. 04 / VERIFYTest creature

Resolution and intake

Names and links are normalized into traceable donor records. When a suitable public repository exists, ReaFuse pins the exact commit used as evidence.

Dissection with REA

REA—Reverse Engineer Anything—extracts capabilities, interfaces and observable behavior. The goal is to understand the product surface, not transplant implementation.

Concept selection

The lab proposes three combinations with different shapes and scopes. You choose one before code generation begins.

Inputs

ReaFuse accepts concise app names, public web links and GitHub repository URLs. More specific donors usually produce more specific results.

spotify × whatsapp
tiktok × duolingo
https://github.com/org/project-a × https://project-b.example

Private local server paths are rejected by the public lab. A donor that cannot be resolved or studied with sufficient evidence may stop before fusion.

Verification

Tests are written before the creature is grown. They cover donor-A behavior, donor-B behavior and the new fusion contract. The final verdict reports what passed—it is not a promise that an experimental prototype is production-ready.

  • ALIVE: the creature satisfied its contract and verification gates.
  • UNSTABLE: useful output exists, but one or more gates need attention.
  • DEAD: generation or verification could not produce a viable creature.

Clean-room rule

ReaFuse learns what donor software does, then generates an independent implementation. It does not intentionally copy donor source, comments, README prose or distinctive internal identifiers.

Originality gateA deterministic scanner compares generated material with studied donor sources. Suspicious shared stretches fail the operation instead of being quietly shipped.

Donor provenance and detected licenses remain visible. Users are responsible for reviewing licenses, generated code and deployment suitability.

Reading a result

A completed run can include its selected concept, pinned donors, contract tests, generated files, originality findings, test totals and an isolated browser preview. Failed runs preserve their timeline so the failure is inspectable rather than erased.

ReaFuse is a proof laboratory: review the output before depending on it, shipping it or connecting it to sensitive data.

Questions still sparking? Open the FAQ →