Fokussierte technische Recherche

Research Problem Framing & Candidate Discovery

Technical research only creates value when it answers a concrete engineering decision. Start every investigation by locking down the decision criteria and checking what the host project already has.

Workflow

1. Frame the decision contract upfront:
   • Extract from the brief (or define concisely if unstated):
     • Problem statement: What exact capability, bottleneck, or integration gap needs solving?
     • Must-have constraints: Runtime/language compatibility (e.g., Node/TS, Python, Rust, browser/SSR), performance bounds, offline/local-first requirements, and security posture.
     • Hard disqualifiers (dealbreakers): Incompatible licenses (e.g., AGPL/SSPL or missing license), mandatory paid cloud lock-in, native C++ build toolchains where pure JS/WASM is required, or abandoned security-critical dependencies.
2. Audit the host codebase first:
   • Inspect the repository's existing dependencies, internal utilities, and architecture before searching externally.
   • Frequently the cleanest solution is an already-installed package, a built-in runtime API, or a 40-line extension of an existing module.
3. Search across all four solution classes: Never limit discovery to "which npm/PyPI package has the most stars". Gather candidates across:
   • Direct libraries / SDKs: Focused packages that solve the specific problem.
   • Reference implementations & production repos: How established open-source projects implement the mechanism internally.
   • Standard protocols & specifications: RFCs, W3C/IETF specs, or wire protocols that can be implemented directly.
   • Scoped in-house implementation: What it would take to write and test a small, zero-dependency module ourselves.
4. Run a fast triage pass before deep-diving:
   • Filter the initial candidate list (10–20 items) down to 2–4 finalists within minutes by checking:
     • License presence and compatibility.
     • Package manifest (package.json, Cargo.toml, pyproject.toml) for runtime target and transitive dependency weight.
     • Whether the core feature actually exists in code rather than on a "Roadmap" section of the README.
   • Stop expanding the search once decision-grade candidates are identified.

Anti-Patterns to Avoid

• Popularity-driven selection: Choosing a 30k-star framework wrapper over a 500-star standards-compliant library without inspecting code quality or fit.
• Unbounded link-dumping: Returning a list of 15 URLs with one-sentence summaries instead of narrowing to ranked, verified finalists.