What's Fixed (Good Work)
  
  - float height added to the master target_data_structure — now consistent with the SSBO and database.
  - Thread count corrected to "five threads."
  - Stale target rule fixed: "timestamp is older than 1 hour" — that's the right semantic.
  - Database numbering gap (missing 5) is closed.
  - int32_t police_boat properly typed in the database table.
  - Database/dynamic state separation clarified — the note that the database holds only physical characteristics
  is important and was missing before.
  - patrol_route.json removed cleanly; simulator owns that logic now.
  - Timing change resolves the A-scope problem I flagged — targets no longer have to wait for north crossing.

  ---
  One Significant New Issue

  float elapsed_seconds will lose precision at current epoch.

  float has roughly 7 significant decimal digits. The current Unix timestamp is about 1,748,000,000 seconds. At
  that magnitude, a float can only distinguish values that are about 128 seconds apart — it cannot tell the
  difference between two timestamps that are minutes or even an hour apart. Your 1-hour stale check would break
  silently.

  This should be int64_t elapsed_seconds (or simply keep the original time_t, which is int64_t on 64-bit Linux).
  In the PostgreSQL column, this maps to BIGINT.

  ---
  Still Unresolved from Before

  The SSBO struct (target_data_to_shader_structure, the block starting around line 142) still has the same
  pseudo-types that were flagged earlier — enum material, binary police_boat, and time_t timestamp. The database
  table was updated to proper types but the SSBO struct wasn't touched. Those three fields in the SSBO struct need
   the same treatment:

  - enum material; → int32_t material;
  - binary police_boat → int32_t police_boat;
  - time_t timestamp; → int64_t timestamp; — and note that std430 will align this to 8-byte boundaries, which may
  pad the struct unexpectedly. Worth documenting.

  Also: may_need_update in the database table still says "binary" rather than a typed value.

  ---
  One Question on the New Timing

  With targets now dispatched "as they arrive," Thread 1 could receive a new target batch at any point during a
  sweep — including mid-frame while the GPU is rendering. The mutex protects the write side, but you'll need to
  decide when Thread 1 actually uploads the new data to the SSBO: at the start of each render frame (safest), or
  immediately on receipt. "Immediately" is fine but should be stated, so the code is written with that in mind.
  Recommend adding one sentence to the Thread 1 description about when it drains the incoming target buffer and
  calls glBufferSubData.

✻ Sautéed for 1m 1s

※ recap: Museum radar simulator in C++/OpenGL. We're specifying the target data pipeline in CLAUDE.md. Next: fix 
  the SSBO struct types — change enum material, binary police_boat, and time_t timestamp to proper int32_t and 
  int64_t types. (disable recaps in /config)
  
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯  
───────────────────────────────────────────────────
