Duplicate runnable entrypoints create split-brain runtime behavior

[tg12]

Summary

WireTapper maintains two divergent executable entrypoints (app.py and app-env.py) with materially different configuration, enrichment, and output behavior, creating split-brain runtime semantics for the same product.

Evidence

• app.py hardcodes provider credential constants in source: https://github.com/h9zdev/WireTapper/blob/main/app.py#L9-L13
• app-env.py switches to environment-backed credentials and adds different enrichment logic: https://github.com/h9zdev/WireTapper/blob/main/app-env.py#L10-L15 and https://github.com/h9zdev/WireTapper/blob/main/app-env.py#L84-L126
• app-env.py augments results through wpasec_kquery and includes additional dummy/leaked fields that are absent from app.py: https://github.com/h9zdev/WireTapper/blob/main/app-env.py#L84-L126 and https://github.com/h9zdev/WireTapper/blob/main/app-env.py#L184-L185
• Both files remain runnable Flask entrypoints with overlapping route purpose.

Why this matters

This is not a cosmetic duplication problem. Which file gets launched changes auth behavior, provider custody, enrichment results, and the shape of returned device data. That makes behavior non-deterministic across environments and turns debugging into guesswork.

Attack or failure scenario

A local demo uses app.py, while another operator or deployment uses app-env.py. Identical requests now return different fields, different leak annotations, and different provider behavior. Defects appear irreproducible because the project has no single authoritative runtime.

Root cause

The project evolved by copying the entrypoint and editing the clone instead of extracting shared logic and preserving one canonical executable path.

Recommended fix

1. Collapse to a single supported entrypoint.
2. Move provider configuration and enrichment behavior into shared modules with explicit feature flags.
3. Add schema tests so returned device structures remain stable across environments.
4. Remove the abandoned or demo-only path from production documentation.

Acceptance criteria

• Only one canonical server entrypoint remains for the product.
• Provider config and enrichment logic are shared, not forked.
• Route responses are deterministic across environments given the same configuration.

Suggested labels

• architecture
• technical-debt
• reliability
• production-readiness

Priority

P1 (High)

Severity

High — duplicated entrypoints create non-deterministic runtime behavior and configuration drift.

Confidence

Confirmed — the divergence is explicit in tracked source.