added original leetcode task

analysis/01-When_Arithmetic_Cannot_Be_Trusted/readme.md

@@ -1,4 +1,4 @@
-# Analysis #01 — When Arithmetic Cannot Be Trusted
+# #01 — When Arithmetic Cannot Be Trusted
 
 ## 1. The Problem
 

analysis/02-Floating_Point_Equality_Is_a_Lie/readme.md

@@ -1,4 +1,4 @@
-# Analysis #02 — Floating Point Equality Is a Lie
+# #02 — Floating Point Equality Is a Lie
 
 ## Problem
 

analysis/03-Two_Sum_Is_Not_About_Numbers/origina-leetcode-task.txt

@@ -0,0 +1,32 @@
+Given an array of integers nums and an integer target, return indices of the two numbers such that they add up to target.
+
+You may assume that each input would have exactly one solution, and you may not use the same element twice.
+
+You can return the answer in any order.
+
+ 
+
+Example 1:
+
+Input: nums = [2,7,11,15], target = 9
+Output: [0,1]
+Explanation: Because nums[0] + nums[1] == 9, we return [0, 1].
+Example 2:
+
+Input: nums = [3,2,4], target = 6
+Output: [1,2]
+Example 3:
+
+Input: nums = [3,3], target = 6
+Output: [0,1]
+ 
+
+Constraints:
+
+2 <= nums.length <= 104
+-109 <= nums[i] <= 109
+-109 <= target <= 109
+Only one valid answer exists.
+ 
+
+Follow-up: Can you come up with an algorithm that is less than O(n2) time complexity?

analysis/03-Two_Sum_Is_Not_About_Numbers/readme.md

@@ -1,4 +1,4 @@
-# Analysis #03 — Two Sum Is Not About Numbers
+# #03 — Two Sum Is Not About Numbers
 
 ---
 
@@ -275,18 +275,43 @@ At this point, the original Two Sum is almost unrecognizable.
 
 See example implementation:
 
-- examples/two_sum_logs_demo.cpp
+- examples/two_sum_logs_demo
 
 ---
 
 ## Example Output
 
-Interview-style reduction:
+```
-  combines events from different request_id → false positive
+Synthetic log stream:
+  2026-04-16T10:15:01.100Z service=api    event=parse_input   latency=12ms request_id=req-1001
+  2026-04-16T10:15:01.110Z service=cache  event=cache_miss    latency=48ms request_id=req-1001
+  2026-04-16T10:15:01.120Z service=auth   event=token_check   latency=58ms request_id=req-2001
+  2026-04-16T10:15:01.130Z service=db     event=read_user     latency=43ms request_id=req-3001
+  2026-04-16T10:15:01.135Z service=db     event=read_user     latency=55ms request_id=req-1001
+  2026-04-16T10:15:01.144Z service=net    event=external_call latency=47ms request_id=req-1001
+  2026-04-16T10:15:01.200Z service=cache  event=cache_miss    latency=60ms request_id=req-3001
+  2026-04-16T10:15:01.260Z service=net    event=external_call latency=52ms request_id=req-3001
 
-Streaming solution:
+Threshold: 100ms
-  finds valid pair within same request and time window
+Time window: 20ms
 
+Interview-style reduction (ignores request_id and time):
+  first : 2026-04-16T10:15:01.110Z service=cache  event=cache_miss    latency=48ms request_id=req-1001
+  second: 2026-04-16T10:15:01.120Z service=auth   event=token_check   latency=58ms request_id=req-2001
+  combined latency: 106ms
+
+Streaming sliding-window detection:
+  first : 2026-04-16T10:15:01.135Z service=db     event=read_user     latency=55ms request_id=req-1001
+  second: 2026-04-16T10:15:01.144Z service=net    event=external_call latency=47ms request_id=req-1001
+  combined latency: 102ms
+
+Notes:
+  - The interview-style version can produce a false correlation.
+  - In this dataset, it first matches 58ms from req-2001 with 43ms from req-3001.
+  - That pair exceeds the threshold, but it is operationally meaningless.
+  - The streaming version only correlates events from the same request_id
+    and only within the configured time window.
+```
 ---
 
 ## Explanation