⏱ Terminal Viewer Gallery — Random Pick

Temporal Navigator

Temporal Link Failed
Traveler: Gino-22-Alpha
Timeline: Unstable
Reviewed: 2026-04-23

Loaded SRC URL

App Behavior

Temporal Navigator is a time-travel dashboard — a JSON-powered interface that presents a fictional traveler's profile, jump history, detected anomalies, and safety protocols as if pulled from a real temporal tracking system. The intended layout has five panels: Traveler Profile, Safety Protocols, Jump History, Detected Anomalies, and a top-level status header showing the traveler's current timeline stability.

The underlying JSON is genuinely creative and fully populated. It includes a traveler ID (Gino-22-Alpha), two time jumps with butterfly-effect consequence arrays, a detected anomaly with an erasure probability score, and a safety protocol block with a paradox threshold and blacklisted dates (WWI and WWII start dates, among others):

// fetched from chenpochun_183136_14904083_pc763.json
{
  "traveler_id": "Gino-22-Alpha",
  "current_timeline_status": "Unstable",
  "origin_anchor": "2026-02-25T18:45:00Z",
  "jump_history": [ // 2 entries — NYC 1994, Mars 2085 ],
  "detected_anomalies": [ // severity 8, erasure prob 0.045 ],
  "safety_protocols": {
    "paradox_threshold": 0.15,
    "blacklisted_dates": [ "1914-07-28", "1939-09-01", ... ]
  }
}

In practice, none of this data ever renders. The app gets stuck at the loading screen and displays "TEMPORAL LINK FAILED — Unable to establish connection" before any panel is populated.

Things That Didn't Work as Expected

⚠ JSON Ownership Mismatch: The app belongs to kongedmondchakchun but hardcodes a JSON path from a different student's file — chenpochun_183136_14904083_pc763.json. This cross-student reference is likely the root cause of the fetch failure, either via a CORS block or a misconfigured URL.
✗ 01
Fetch fails entirely — "TEMPORAL LINK FAILED." Despite the JSON being publicly accessible and well-formed, the app never successfully loads it. All five content panels remain empty. This is the single issue that breaks the entire experience.
✗ 02
RETRY CONNECTION button likely retries the same broken fetch. Without fixing the underlying URL or CORS issue, retrying will always produce the same failure — there is no fallback or alternative endpoint.
✗ 03
No graceful degradation. A failed fetch should ideally fall back to mock/placeholder data so the UI's visual design is still demonstrable. Instead, every panel is a blank header with no content.
✗ 04
Wasted creative potential. The JSON itself is one of the most imaginative in the gallery — butterfly-effect arrays, a paradox threshold, blacklisted historical dates. None of it is visible because the fetch never completes.
✗ 05
Loading state has no timeout. "SYNCHRONIZING TIMELINE DATA..." shows briefly before the failure message, but there is no timeout or max-retry logic — the UI could hang indefinitely depending on network behavior.

Prompt to Improve the App

// improvement prompt — temporal-navigator v2

"Fix and extend Temporal Navigator with the following changes:"

  1. Fix the JSON source URL. Update the hardcoded fetch path to point to the correct student-owned JSON file (matching the kongedmondchakchun prefix), or add a proper CORS header to the existing pc763.json endpoint so cross-origin fetches succeed.
  2. Add a fallback to inline mock data. If the fetch fails or times out, populate all panels with the hardcoded JSON so the visual design is always demonstrable — display a small "⚠ Offline mode" chip to indicate the fallback is active.
  3. Render Jump History as a visual timeline. Display each jump_history entry as a card showing destination date, location, objective, and an expandable list of butterfly effects. Use a connecting vertical line between cards to reinforce the timeline metaphor.
  4. Display anomaly severity as a gauge. Render each detected_anomalies entry with a visual severity bar (0–10) and a color-coded erasure probability indicator — green below 5%, amber 5–15%, red above.
  5. Enforce blacklisted dates interactively. Add a date-input field where the user can enter a target jump date; check it against blacklisted_dates and show a red "JUMP PROHIBITED" warning if it matches, or a green "CLEARANCE GRANTED" if safe.