Skip to content

Evaluate archiving or decommissioning this repository due to accumulated trust-boundary and data-fidelity defects #10

Description

@tg12

Summary

The current issue trail indicates this repository should be evaluated for archival, decommissioning, or a prominent unsupported/experimental label rather than being left standing as a credible live geospatial intelligence platform.

Evidence

The open issue set already documents structural trust failures in core live surfaces:

  • #6 Flights snapshot endpoint fabricates 400 moving aircraft when provider telemetry fails.
  • #7 Flight-track client defaults to MockClient and silently disables track history unless env is set.
  • #8 GulfWatch layer renders loading as an all-clear state across every emirate.
  • #9 Cyber API exposes an unauthenticated generic proxy to Cloudflare Radar.

Why this matters

This is not a narrow bug cluster. It cuts across the core claims of the product: live aviation telemetry, threat-alert truthfulness, and safe provider-backed cyber intelligence. A system that swaps in fabricated aircraft, mock providers, fake all-clear states, and public token-backed proxying should not be treated as a trustworthy situational-awareness surface.

Failure scenario

The platform remains public and is used as a live intelligence map. Upstream flight telemetry fails, the server substitutes synthetic aircraft, the GulfWatch layer visually implies calm before alert data arrives, and the cyber routes continue to proxy authenticated third-party requests for any caller. The UI still looks authoritative while the underlying contract is broken.

Root cause

The repository favors continuous interface output over truthful degraded-state representation and exposes provider-backed capability with insufficient boundaries.

Recommended fix

  1. Decide explicitly whether this repository is meant to remain a maintained public platform.
  2. If not, archive it or mark it unsupported and not safe for operational use.
  3. If it remains active, publish a remediation plan for synthetic fallback removal, provider-mode hardening, threat-layer state accuracy, and proxy boundary tightening.
  4. Remove or clearly label any public deployment until those defects are resolved.

Acceptance criteria

  • Maintainers state whether the project is active, experimental, unsupported, or abandoned.
  • If unsupported, the repository is archived or prominently marked as not for operational use.
  • If supported, a remediation plan exists for the issue set above.

Suggested labels

  • production-readiness
  • architecture
  • security

Severity

High — the current implementation can present a live operational picture that is at times fabricated, mis-signaled, or weakly bounded.

Confidence

Confirmed — this recommendation is based on multiple open, issue-backed defects already documented in the public tracker.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions