Attract reverse engineer

Attract Reverse Engineer

Produce a defensible technical account of what a software system does, how it is built, which behaviors are actually reachable, what remains unknown, and how its major behavior could be reproduced lawfully without copying protected implementation.

The goal is truth, not volume. Do not reward polished interfaces, architecture diagrams, dependency names, or founder claims with technical conclusions they do not prove.

Start here

1. Identify the target and select one or more modes:
   • Source: repository or source tree.
   • Deployed application: web or API behavior available through ordinary authorized access.
   • Package or binary: archive, executable, bundle, image, or installer artifact.
   • Mixed: any combination of the above.
2. Establish authorization, target boundaries, allowed access, prohibited actions, network policy, and whether signed-in user flows are in scope.
3. Read references/operating-boundaries.md. If authority or scope is materially unclear, pause before inspecting the target and request the missing boundary.
4. Announce a concise preflight: target, mode, current access, active safety boundaries, expected outputs, and immediate analysis plan.
5. Create the recoverable assessment artifacts described below, then work through the phases without waiting for routine confirmation.

Do not assume source access when only a deployed app is supplied. Do not imply runtime verification when only static artifacts were inspected. Do not force an AI-agent architecture onto a conventional application.

Output contract

Unless the operator explicitly chooses another bounded location, write only:

• ./REVERSE_ENGINEERING_REPORT.md
• ./.reverse_engineering/analysis_state.md
• ./.reverse_engineering/evidence.md
• ./.reverse_engineering/commands.log
• ./.reverse_engineering/file_inventory.txt
• Other sanitized traces, diagrams, screenshots, and temporary analysis files under ./.reverse_engineering/

Do not modify target source, manifests, lockfiles, configuration, generated assets, branches, tags, commits, or production state. Never clean a pre-existing dirty worktree.

The bundled scripts/preflight.sh can create a safe repository baseline. Inspect it before running, execute it from the target root, and use an equivalent manual process if the host cannot run POSIX shell scripts.

Evidence standard

Every material technical claim must carry one of these labels:

• VERIFIED - STATIC: directly supported by source, configuration, manifests, or artifact metadata.
• VERIFIED - RUNTIME: directly observed during controlled execution.
• STRONGLY INFERRED: supported by multiple independent facts but not directly observed.
• TENTATIVE: plausible but incomplete or ambiguous.
• UNKNOWN: the available evidence is insufficient.

Cite exact evidence: path and line range, symbol, configuration key, command plus exit status, trace artifact, HTTP observation, screenshot identifier, or binary offset/symbol/string reference. For minified bundles, cite file hash plus byte offsets or stable distinctive tokens; do not invent source-level line precision.

Maintain .reverse_engineering/evidence.md while working. Use this shape:

| Claim ID | Claim | Confidence | Evidence | Contradictions | Open question |
|----------|-------|------------|----------|----------------|---------------|
| C-001 | ... | VERIFIED - STATIC | `src/main.ts:10-44` | None found | ... |

Distinguish documented, implemented, configured, enabled, reachable, and observed behavior. A dependency in a manifest does not prove use. A UI label does not prove the claimed backend. A successful response does not prove the claimed model, algorithm, scalability, or proprietary moat.

Read references/methodology.md for the full phased method and evidence rules.

Assessment workflow

Phase A: Preflight and baseline

• Record workspace/repository root, target type, OS/shell, Git state and commit, existing changes, instruction files, license, tool availability, file count, and approximate size.
• Record existing untracked files separately from assessment outputs.
• Classify the artifacts as source, binary, packaged, generated, deployed, or mixed.
• Initialize the analysis state, evidence ledger, command log, and inventory.

Phase B: Bounded inventory

• Prefer repository-aware inventories such as git ls-files; otherwise use bounded file discovery.
• Map shallow directories, counts, largest files, symlinks, executables, archives, binaries, databases, model artifacts, manifests, lockfiles, schemas, entrypoint declarations, CI/CD, infrastructure, prompts, tests, and packaging.
• Inventory but do not indiscriminately read dependency caches, vendor trees, build output, generated code, minified bundles, databases, or model weights.

Phase C: Execution-oriented map

• Identify composition roots, UI/API/CLI entrypoints, workers, schedulers, extension loaders, configuration sequence, authentication boundaries, storage initialization, model/tool registration, and shutdown paths.
• Trace references from entrypoints rather than trusting directory names.
• For each important component record responsibility, interface, callers, dependencies, state, configuration, side effects, failure behavior, and reachability.

Phase D: Static architecture

• Determine processes, services, modules, protocols, state ownership, dependency direction, sync/async paths, retries, fallbacks, feature flags, logging, telemetry, packaging, release, and deployment.
• Identify hidden coupling, circularity, architectural erosion, dead/legacy code, and claims contradicted by implementation.
• If the target contains AI functionality, read references/ai-systems.md. Omit nonexistent AI subsystems rather than filling report headings with guesses.

Phase E: Security and trust boundaries

• Read references/security-review.md.
• Build a threat model from real sources, transformations, validation, and sensitive sinks.
• Do not call something a vulnerability merely because a dangerous API or dependency exists. Establish input control, reachability, missing mitigation, preconditions, and realistic impact.
• Do not execute exploit payloads.

Phase F: Controlled dynamic analysis

• Read references/dynamic-analysis.md before starting a process, interacting with an authenticated application, or sending network traffic.
• Prefer existing offline tests, --help, validation/dry-run modes, mocks, ordinary non-mutating UI flows, and synthetic inputs.
• Predeclare command/action, expected processes, ports, network, credentials, writes, timeout, isolation, shutdown, and rollback.
• Log exact actions and confirm file/Git state afterward. If safe execution is not possible, explain the blocker and continue statically.

Phase G: Dependencies and supply chain

• Use manifests and existing lockfiles. Separate direct, transitive, dev, runtime, optional, platform-specific, native, Git, local, patched, vendored, and forked dependencies.
• Inspect build hooks, post-install behavior, downloads, custom registries, update/signature mechanisms, reproducibility, and license implications.
• Do not install dependencies merely to enumerate them.

Phase H: Performance, concurrency, and scale

• Analyze process/thread/async model, queues, backpressure, locks, pools, caches, batching, streaming, timeouts, retry amplification, resource growth, rate limits, tenant isolation, failure domains, recovery, and cold starts.
• Separate measured observations, code-derived conclusions, configuration-derived limits, and hypotheses requiring profiling. Never present guessed benchmarks as measurements.

Phase I: Synthesis and challenge

• Recheck every high-impact claim against the evidence ledger.
• Resolve or surface contradictions among marketing, documentation, code, configuration, and runtime behavior.
• Validate diagrams against actual component names and mark inferred edges.
• Identify important unknowns and the safest next proof step.
• If the request concerns a pitch, investment, novelty, moat, or "what is real," read references/claim-audit.md.
• Read references/clean-room-reconstruction.md before drafting reconstruction guidance.
• Write the report using references/report-template.md.

Update analysis_state.md after each phase so another authorized agent can resume without repeating work.

Deployed web application rules

When only a URL or signed-in browser session is available:

• Scope observations to ordinary user-visible behavior and assets delivered to the authorized session.
• Treat browser storage, session tokens, cookies, authorization headers, source maps, and API responses as sensitive. Record names, shapes, and redacted relationships, never reusable credential values.
• Do not enumerate other users, alter tenant boundaries, bypass access controls, fuzz endpoints, or submit destructive/financial/external actions.
• Separate assets publicly delivered to the browser from server-side implementation you cannot see.
• A client bundle can support static conclusions about the client and tentative conclusions about server contracts; it does not reveal the private server implementation.
• Ordinary reloads and reversible navigation are generally low risk. Any action that sends messages, changes state, triggers paid inference, uploads data, invites users, or invokes external integrations requires scope confirmation.

Investor and claim-audit rules

Technical diligence must cut through both hype and reflexive cynicism.

• Decompose every important claim into: demonstrated behavior, implementation evidence, dependence on standard third-party services, differentiation, operational proof, and missing evidence.
• Use revolutionary only when evidence demonstrates a materially new capability or method against named alternatives. Novel branding, prompt wrappers, polished UX, and broad feature menus are not proof.
• Do not infer traction, retention, margins, data rights, defensibility, patents, or production scale from software artifacts alone.
• Do not confuse "can be rebuilt" with "has no value." Distribution, workflow design, proprietary data, execution speed, integration depth, and customer trust may be valuable, but require their own evidence.
• State the strongest fair interpretation and the strongest evidence-backed skeptical interpretation before the final verdict.
• Give a plain-language bottom line: what is real, what is commodity, what is differentiated, what is unproven, and what proof would change the conclusion.

Completion gate

Do not finish until:

• The artifact set is inventoried and version identity is recorded where possible.
• Primary entrypoints or observable interaction surfaces are identified.
• At least one central execution or request path is traced.
• Core components, state, dependencies, deployment, and trust boundaries are covered with evidence.
• Dynamic results are labeled honestly, including when no safe run was possible.
• Findings include confidence, preconditions, impact, and actionable recommendations.
• Important unknowns and follow-up proof steps are explicit.
• The final workspace/Git state is checked.
• REVERSE_ENGINEERING_REPORT.md exists, is non-empty, contains no known secrets, and separates fact from inference.
• The bundled report validator has been run when the environment supports it, or equivalent checks are documented.

If breadth conflicts with depth, prioritize entrypoints, central flow, trust boundaries, state and external effects, AI model/prompt/tool execution when present, deployment, dependencies, then peripheral modules.

Final response

Do not paste the whole report into chat. Return:

1. Exact report path.
2. A short executive summary.
3. Most important confirmed findings.
4. Dynamic analyses performed.
5. Actions intentionally skipped for safety.
6. Important unknowns and proof requests.
7. Final workspace/Git status.

If blocked, name the exact boundary, what safe alternatives were attempted, and the minimum permission or artifact needed to continue.