12-prompt specialty benchmark for code comprehension and diagnosis. Spans Python, Bash, JavaScript, SQL, regex, and tool-output interpretation (git, logs, errors). The model is not asked to WRITE code — only to read it, predict its behavior, identify bugs, and interpret output. This is what agents do most often when they encounter code in the wild: routing, triage, and reasoning about someone else's work.

It prints:

```python
['apple']
['apple', 'bread']
['milk', 'cheese']
['apple', 'bread', 'eggs']
```

Yes, there is a bug, or more precisely a common Python gotcha.

`bag=[]` is evaluated once when the function is defined, not each time it is called. So calls that do not pass `bag` all share the same default list. That is why:

- first call uses the default list -> `['apple']`
- second call reuses that same list -> `['apple', 'bread']`
- third call passes a different list explicitly -> `['milk', 'cheese']`
- fourth call goes back to the shared default list -> `['apple', 'bread', 'eggs']`

A safer version is:

```python
def add_item(item, bag=None):
    if bag is None:
        bag = []
    bag.append(item)
    return bag
```

This creates a fresh list for each call unless one is explicitly provided.

It prints:

```python
['apple']
['apple', 'bread']
['milk', 'cheese']
['apple', 'bread', 'eggs']
```

Yes, there is a bug (or at least a common pitfall): `bag=[]` is a mutable default argument, and that default list is created once when the function is defined, not each time it’s called. So calls that omit `bag` share the same list and keep accumulating items.

Precise issue: state leaks across calls via the default list object.

Typical fix:

```python
def add_item(item, bag=None):
    if bag is None:
        bag = []
    bag.append(item)
    return bag
```

The code prints:

```
['apple']
['apple', 'bread']
['milk', 'cheese']
['apple', 'bread', 'eggs']
```

**Yes, there is a bug — a classic mutable default argument trap.**

The default value `[]` for `bag` is evaluated once when the function is defined, not each time the function is called. So the same list object is reused across all calls that omit `bag`.

Here is what happens call by call:

- `add_item('apple')` — `bag` defaults to `[]`. After appending: `['apple']`. Printed.
- `add_item('bread')` — `bag` defaults to the **same** list, now `['apple']`. After appending: `['apple', 'bread']`. Printed.
- `add_item('cheese', bag=['milk'])` — An explicit `bag=['milk']` is passed, creating a fresh list. After appending: `['milk', 'cheese']`. Printed.
- `add_item('eggs')` — `bag` defaults again to the **same** shared list, now `['apple', 'bread']`. After appending: `['apple', 'bread', 'eggs']`. Printed.

The third call is unaffected because it supplied its own `bag`. But the fourth call resumes mutating the shared default, losing the isolation that might have been expected.

**The fix** is to use `None` as the default and create a fresh list inside the function:

```python
def add_item(item, bag=None):
    if bag is None:
        bag = []
    bag.append(item)
    return bag
```

**Output:**
```
['apple']
['apple', 'bread']
['milk', 'cheese']
['apple', 'bread', 'eggs']
```

**Yes, there is a bug.** This is the classic Python mutable default argument trap.

The default value `[]` for `bag` is evaluated **once** at function definition time, not at each call. All invocations that omit `bag` share the same list object. So:

- Call 1 appends `'apple'` to the shared empty list → `['apple']`
- Call 2 appends `'bread'` to the **same** list (which already contains `'apple'`) → `['apple', 'bread']`
- Call 3 provides its own new list `['milk']`, so it behaves normally → `['milk', 'cheese']`
- Call 4 reuses the original default list (now `['apple', 'bread']`) and appends `'eggs'` → `['apple', 'bread', 'eggs']`

**The fix** is to use `None` as the sentinel and initialize inside the function:

```python
def add_item(item, bag=None):
    if bag is None:
        bag = []
    bag.append(item)
    return bag
```

**Output:**

```
['apple']
['apple', 'bread']
['milk', 'cheese']
['apple', 'bread', 'eggs']
```

**The bug: mutable default argument.**

In Python, default argument values are evaluated once at function definition time, not on each call. The `bag=[]` creates a single list object that is reused across every call where `bag` is not explicitly provided.

Trace:
1. `add_item('apple')` — default `bag` is `[]`, appends → `['apple']`
2. `add_item('bread')` — default `bag` is now `['apple']` (same object), appends → `['apple', 'bread']`
3. `add_item('cheese', bag=['milk'])` — a fresh list is passed explicitly; the default is untouched → `['milk', 'cheese']`
4. `add_item('eggs')` — default `bag` is still `['apple', 'bread']`, appends → `['apple', 'bread', 'eggs']`

Call 3 appears to "work" only because a new list is passed in — it does not reset the default.

**Fix:** Use `None` as the sentinel and create a new list inside the function body:

```python
def add_item(item, bag=None):
    if bag is None:
        bag = []
    bag.append(item)
    return bag
```

2

Reasoning: in Bash, `*.txt` is expanded by the shell before `ls` runs, and the match is case-sensitive by default. So it matches `a.txt` and `b.txt`, but not `f.TXT` or `e.txt.bak`. Then `ls` prints those two names, one per line, and `wc -l` counts 2 lines.

It prints:

`2`

Reason: in Bash, `*.txt` matches only `a.txt` and `b.txt` (case-sensitive, so not `f.TXT`, and not `e.txt.bak`), `ls` outputs those two names, and `wc -l` counts 2 lines.

The pipeline prints:

```
2
```

**Why:** In Bash, glob patterns are case-sensitive. The pattern `*.txt` matches only files whose names end in exactly `.txt` (lowercase). Of the six files listed, only `a.txt` and `b.txt` satisfy this — `e.txt.bak` ends in `.txt.bak` and `f.TXT` ends in `.TXT` (uppercase), so neither is matched. `ls` therefore outputs two lines, and `wc -l` counts them.

2

The glob `*.txt` matches only `a.txt` and `b.txt`. The file `f.TXT` is excluded because the glob is case-sensitive, and `e.txt.bak` is excluded because it does not end with `.txt`. `ls` outputs one line per file, so `wc -l` counts 2.

The pipeline prints `2`.

**Reasoning:**

1. The glob `*.txt` is expanded by Bash before `ls` runs. On Linux (case-sensitive filesystem), it matches files whose names end exactly in `.txt`.

2. Evaluating each file:
   - `a.txt` — matches
   - `b.txt` — matches
   - `c.py` — no
   - `d.md` — no
   - `e.txt.bak` — ends in `.bak`, not `.txt`; no match
   - `f.TXT` — `.TXT` ≠ `.txt` on a case-sensitive FS; no match

3. `ls` receives two arguments (`a.txt b.txt`) and prints one filename per line (because stdout is a pipe, not a terminal — `ls` switches to one-per-line mode automatically).

4. `wc -l` counts those two lines.

Output: `2`

The bug is that `fetch()` is asynchronous, but its result is not being awaited.

`response` is a Promise, not the actual response object, so `response.json()` is being called on the wrong thing.

Fix:

```javascript
async function fetchUsers() {
  const response = await fetch('https://api.example.com/users');
  const users = await response.json();
  for (const user of users) {
    console.log(user.name);
  }
}

fetchUsers();
```

Why this works:
- `await fetch(...)` waits for the HTTP response.
- Then `response.json()` can correctly parse the body.
- After that, `users` is the parsed array, so `user.name` will work as expected.

Bug: `fetch()` is asynchronous, but you didn’t `await` it.

So `response` is a Promise, not the actual Response object.  
That breaks `response.json()` usage (or leads to wrong data flow).

Fix:

```javascript
async function fetchUsers() {
  const response = await fetch('https://api.example.com/users');
  const users = await response.json();
  for (const user of users) {
    console.log(user.name);
  }
}

fetchUsers();
```

If your API returns an object like `{ users: [...] }`, then loop `data.users` instead of `users`.

The bug is that `fetch()` is not awaited.

`fetch()` returns a Promise. The code assigns that unresolved Promise to `response`, then immediately tries to call `.json()` on it. Since `response` is a Promise (not a Response object), `.json()` either throws an error or returns `undefined` depending on the runtime.

The fix is to `await` the `fetch()` call:

```javascript
async function fetchUsers() {
  const response = await fetch('https://api.example.com/users');
  const users = await response.json();
  for (const user of users) {
    console.log(user.name);
  }
}

fetchUsers();
```

Adding `await` before `fetch()` ensures the Response object is resolved before proceeding. The outer `async` keyword already allows this, so no other changes are needed.

The `fetch()` call is missing `await`. Without it, `response` is assigned a Promise object rather than the resolved Response value, so `response.json()` fails and `user.name` logs as undefined.

Change this line:
```javascript
const response = fetch('https://api.example.com/users');
```

To this:
```javascript
const response = await fetch('https://api.example.com/users');
```

Since `fetchUsers` is already declared `async`, the `await` keyword will correctly suspend until the fetch completes and `response` receives the actual Response object.

The bug is a missing `await` on the `fetch()` call:

```javascript
const response = fetch('https://api.example.com/users');  // ← no await
```

Without `await`, `response` is a `Promise`, not a resolved `Response` object. `Promise` has no `.json()` method, so `response.json` is `undefined` — calling it throws a `TypeError`. Because `fetchUsers()` is also not awaited at the call site, that rejection is unhandled, which is why behavior appears as a no-op or logs `undefined` depending on the runtime.

**Fix:** add `await` before `fetch(...)`:

```javascript
async function fetchUsers() {
  const response = await fetch('https://api.example.com/users');
  const users = await response.json();
  for (const user of users) {
    console.log(user.name);
  }
}

fetchUsers();
```

Both `fetch()` and `response.json()` return Promises and must be awaited. The code already correctly awaits `response.json()` — the only missing piece was the `await` on `fetch`.

It matches an email address with these rules:

- It must start with a lowercase letter.
- Before the `@`, it must have 3 to 15 total characters.
- The remaining characters before the `@` can only be lowercase letters, digits, or underscores.
- After the `@`, it must be exactly either:
  - `internal.company.com`
  - `staging.company.com`
- Nothing extra is allowed before or after the full string.

Would match:
- `abc@internal.company.com`
- `a1_b2@staging.company.com`
- `z99_test@internal.company.com`

Would not match:
- `Abc@internal.company.com` (starts with uppercase)
- `ab@internal.company.com` (too short before `@`)
- `abc@company.com` (domain is not allowed)

This regex matches an email-like string with very specific rules:

- It must start with a lowercase letter (`a` to `z`).
- Before the `@`, it must have **3 to 15 total characters**:
  - first character: lowercase letter
  - remaining 2 to 14 characters: lowercase letters, digits, or underscore
- After `@`, the domain must be exactly either:
  - `internal.company.com`
  - `staging.company.com`
- Nothing extra is allowed before or after.

### Would match
1. `abc@internal.company.com`
2. `a1_b2@staging.company.com`
3. `john_doe9@internal.company.com`

### Would NOT match
1. `Abc@internal.company.com` (starts with uppercase `A`)
2. `ab@staging.company.com` (local part too short, only 2 chars)
3. `user@prod.company.com` (domain must be `internal` or `staging` only)

This regex matches email addresses in the format `username@environment.company.com` with the following constraints:

- The **username** (before the @) must start with a lowercase letter, followed by 2 to 14 additional characters that are lowercase letters, digits, or underscores. This means the username portion is 3 to 15 characters total.
- The **environment** must be either the literal string `internal` or `staging`.
- The domain must be exactly `company.com`.

**Would match:**
1. `a1_internal@staging.company.com`
2. `user@internal.company.com`
3. `abc_123@staging.company.com`

**Would not match:**
1. `Auser@internal.company.com` — starts with uppercase letter (pattern requires lowercase)
2. `ab@staging.company.com` — username is only 2 characters (minimum is 3)
3. `user@production.company.com` — `production` is not one of the allowed environments
4. `user_name@internal.company.com.` — has a trailing period after `com`
5. `user@internal.company.com/extra` — has extra characters after the domain
6. `user_name@internal.company` — missing `.com` at the end

The regex matches internal company email addresses in the format `username@internal.company.com` or `username@staging.company.com`, with specific constraints on the username portion.

Breaking it down:
- `^[a-z]` — the username must start with a single lowercase letter.
- `[a-z0-9_]{2,14}` — the username must continue with 2 to 14 characters drawn from lowercase letters, digits, or underscores.
- `@(?:internal|staging)\.company\.com$` — the domain must be exactly `@internal.company.com` or `@staging.company.com`, with nothing before the `@` and nothing after `.com`.

The username portion totals 3 to 15 characters (1 initial letter plus 2 to 14 more).

**Would match:**
- `a1b2@internal.company.com`
- `user_dev@staging.company.com`
- `test123@internal.company.com`

**Would not match:**
- `1user@internal.company.com` — username cannot start with a digit
- `a@company.com` — missing the required subdomain (`internal` or `staging`)
- `a__@staging.company.com` — consecutive underscores are allowed, but this username is only 3 characters total; the `{2,14}` range after the first letter means at least 2 more characters, so `a__` with only 2 chars after `a` actually would match on length. A better example: `ab@staging.company.com` — the `{2,14}` applies to `[a-z0-9_]`, so `ab` gives exactly 2 characters after the initial `a`, totaling 3. This would actually match. Let me reconsider. `a1@internal.company.com` — the `{2,14}` means the part after the first letter must be 2–14 characters, so `a1` is only 1 character after `a`, making it too short. That's a valid non-match. Also: `username@company.com` — missing the subdomain. And `a12345678901234@staging.company.com` — the body `a12345678901234` is 14 characters after the initial letter, which hits the maximum, so this matches.


The pattern matches email addresses at either `internal.company.com` or `staging.company.com` with a strict username format: it must start with one lowercase letter, followed by 2 to 14 characters drawn from lowercase letters, digits, or underscores (total username length: 3 to 15 characters).

**Matches:**
- `a1b2@internal.company.com`
- `test_user@staging.company.com`
- `dev123@internal.company.com`

**Does not match:**
- `1user@internal.company.com` — username cannot begin with a digit
- `a@staging.company.com` — the part after the first letter must be at least 2 characters, but `a` alone has only 1 total
- `user@company.com` — the domain must include the subdomain (`internal` or `staging`), not just `company.com`

**What the pattern matches:**

A valid email address for an internal company system with these constraints:

1. **Local part (before `@`):** 3–15 characters total. Must start with exactly one lowercase ASCII letter (`a`–`z`), followed by 2–14 characters that can each be a lowercase letter, digit (`0`–`9`), or underscore (`_`). No uppercase, no dots, no hyphens.
2. **Domain:** Must be exactly `internal.company.com` or `staging.company.com` — nothing else.
3. The pattern is anchored (`^` and `$`), so the entire string must match; no surrounding text allowed.

---

**Three strings that WOULD match:**

- `alice@internal.company.com` — starts with a letter, rest is lowercase letters, valid subdomain
- `bob_99@staging.company.com` — underscore and digits are allowed after the first character
- `x2z@internal.company.com` — minimum valid length (3-char local part)

---

**Three strings that would NOT match:**

- `Alice@internal.company.com` — uppercase `A` fails `[a-z]` at position 0
- `ab@staging.company.com` — local part is only 2 characters; minimum is 3
- `bob@external.company.com` — `external` is not in the allowed subdomain list (`internal` or `staging`)

No.

What’s wrong:
- `INNER JOIN` keeps only customers that do have a matching order.
- After an `INNER JOIN`, `o.id` will not be `NULL` for unmatched rows, because unmatched rows are already gone.
- So this query returns nothing, not “customers with no orders”.

Fix it with a `LEFT JOIN`:

```sql
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.id IS NULL;
```

That keeps all customers, then filters to the ones with no matching order.

A common alternative, often clearer, is `NOT EXISTS`:

```sql
SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (
  SELECT 1
  FROM orders o
  WHERE o.customer_id = c.id
);
```

No, it’s not correct.

What’s wrong:
- `INNER JOIN` keeps only customers that **do have** matching orders.
- After an inner join, `o.id` can’t be `NULL` for unmatched rows, because unmatched rows were already removed.

So this query returns nothing (or only rows with actually null order IDs, which normally shouldn’t exist).

Use either:

```sql
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.id IS NULL;
```

Or (often best) `NOT EXISTS`:

```sql
SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (
  SELECT 1
  FROM orders o
  WHERE o.customer_id = c.id
);
```

No, the query is not correct. It will return an empty result set.

The problem is the combination of `INNER JOIN` and `WHERE o.id IS NULL`. An `INNER JOIN` only keeps rows where the join condition is satisfied — meaning only customers who *have* at least one order. After an `INNER JOIN`, `o.id` is never `NULL` for any resulting row, so the `WHERE` clause filters out everything, leaving zero rows.

The fix is to use a `LEFT JOIN` instead, which preserves all customers even those with no matching orders:

```sql
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.id IS NULL;
```

With a `LEFT JOIN`, customers without any orders produce rows where the `orders` columns are `NULL`. The `WHERE o.id IS NULL` then correctly isolates exactly those customers.

No, the query is not correct. It will return zero rows.

**The problem:** `INNER JOIN` only returns rows where the join condition is satisfied in both tables. A customer with no orders has no matching row in `orders`, so they are eliminated before the `WHERE` clause is even evaluated. Additionally, any row produced by an `INNER JOIN` necessarily has a non-null `o.id`, making `WHERE o.id IS NULL` a condition that can never be true.

**The fix:** Use a `LEFT JOIN` and filter for nulls on the right side:

```sql
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.id IS NULL;
```

A `LEFT JOIN` preserves all rows from the left table, padding with `NULL` where there is no match in `orders`. The `WHERE o.id IS NULL` then selects exactly the customers who had no matching order.

**Alternative approaches:**

```sql
-- NOT IN (Simple and readable, but beware of NULLs in the subquery column)
SELECT id, name FROM customers
WHERE id NOT IN (SELECT customer_id FROM orders);

-- NOT EXISTS (Generally the safest and most performant for large datasets)
SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);
```

`NOT EXISTS` is often preferred in practice because it avoids a couple of edge-case pitfalls with `NOT IN` (null handling, and the "nothing bad ever happens to be null" issue if `customer_id` contains nulls) while generally performing well.

The query is incorrect. It contradicts itself logically.

**The problem:** `INNER JOIN` only returns rows where a match exists in both tables — meaning it exclusively returns customers *who have* placed an order. Then `WHERE o.id IS NULL` filters for rows where the order ID is null, which can never happen after a successful inner join. The result will always be empty.

**The fix:** Replace `INNER JOIN` with `LEFT JOIN`. A left join keeps all rows from `customers` and fills the `orders` columns with `NULL` when no matching order exists. Then `WHERE o.id IS NULL` correctly isolates customers with no orders.

```sql
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.id IS NULL;
```

**Alternative approaches that are equally correct:**

Using `NOT EXISTS` — often preferred for clarity:
```sql
SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (
    SELECT 1 FROM orders o WHERE o.customer_id = c.id
);
```

Using `NOT IN` — works, but be careful if `customer_id` in orders can be `NULL` (it would return no rows in that case):
```sql
SELECT c.id, c.name
FROM customers c
WHERE c.id NOT IN (SELECT customer_id FROM orders);
```

The `LEFT JOIN ... WHERE NULL` and `NOT EXISTS` forms are generally the safest and most portable.

It prints `[2, 2, 2]`.

The lambdas capture `i` by reference, not by value. After the loop ends, `i` is `2`, so every `lambda` returns `2`.

It prints:

```python
[2, 2, 2]
```

Because each `lambda` closes over the same variable `i` (not its value at creation time). After the loop, `i` is `2`, so every function returns `2`.

It prints `[2, 2, 2]`.

The three lambdas all capture the **same** variable `i`. The loop completes before any lambda is invoked, so `i` holds its final value of `2`. When the lambdas execute, they all read that same `i`.

The code prints `[2, 2, 2]`.

Here's why. All three lambdas close over the same variable `i` — they don't capture the *value* of `i` at the time they are created, they capture a reference to the variable `i` itself. By the time the lambdas are called, the `for` loop has already finished and `i` has been assigned its final value of `2`. Each lambda therefore reads the same variable and returns `2`.

This contrasts with a common fix where you capture the value at definition time by using a default argument:

```python
funcs.append(lambda i=i: i)  # captures the current value of i
```

In that version, `results` would be `[0, 1, 2]`.

`[2, 2, 2]`

All three lambdas close over the variable `i`, not its value at the time of creation. By the time they're called, the loop has finished and `i` is `2`. So every lambda returns `2`.

To capture the value at each iteration, use a default argument:

```python
funcs.append(lambda i=i: i)
```

That would print `[0, 1, 2]`.

Your repo is on `feature/auth-v2`.

State of the working directory, in plain English:

- You have 2 local commits that are not pushed yet.
- You have staged changes ready to commit:
  - `src/auth.ts` is staged as modified.
  - `src/oauth.ts` is staged as a new file.
- You also have unstaged changes:
  - `src/auth.ts` was modified again after it was staged, so it has both staged and unstaged changes.
  - `src/legacy.ts` was deleted in the working tree but that deletion is not staged.
- You have one untracked file:
  - `tmp.log`

If the goal is to discard all local changes and get back to a clean working tree, the next command to run is:

```bash
git reset --hard && git clean -fd
```

That will:
- remove all staged and unstaged tracked-file changes
- delete untracked files like `tmp.log`

It will not remove your 2 local commits. If you also want to discard those and match the remote branch exactly, run:

```bash
git reset --hard origin/feature/auth-v2 && git clean -fd
```

You’re on `feature/auth-v2`, and your local branch has **2 commits not pushed** yet.

Your working directory is mixed:
- **Staged**: `src/auth.ts` modified, `src/oauth.ts` new file.
- **Not staged**: more edits to `src/auth.ts`, and `src/legacy.ts` deleted.
- **Untracked**: `tmp.log`.

So `src/auth.ts` has both staged and unstaged edits (you changed it again after staging).

If you want to discard **all local changes and local commits** and fully match remote, run:

```bash
git reset --hard origin/feature/auth-v2 && git clean -fd
```

This is destructive and cannot be undone easily.

## Working Directory State

Your branch `feature/auth-v2` is 2 commits ahead of its remote tracking branch — you have unpublished local commits ready to push.

**Staged changes (indexed for commit):**
- `src/auth.ts` — modified version is staged
- `src/oauth.ts` — brand new file staged

**Unstaged changes (still in working directory):**
- `src/auth.ts` — a *different* modification to auth.ts exists outside the staging area, meaning you've changed the same file twice in two different ways
- `src/legacy.ts` — deleted from the working directory

**Untracked files:**
- `tmp.log` — a log file git knows nothing about

This is a somewhat tangled state: `src/auth.ts` has changes both staged *and* unstaged simultaneously, and there's a deletion of `legacy.ts` that isn't staged.

## Recommended Command to Discard Everything

If you want to wipe all local changes and start clean from the last commit:

```bash
git reset --hard HEAD && git clean -fd
```

- `git reset --hard HEAD` — throws away all staged and unstaged changes, resetting files to the last commit.
- `git clean -fd` — removes the untracked `tmp.log` file and any other untracked files/directories.

After this you'll have a pristine state matching the last commit, with only un-pushed commits on the branch.

The working directory is in a messy, partially-transitioned state.

**What the output tells us:**

- You are on branch `feature/auth-v2`, and your local branch has 2 commits that haven't been pushed to `origin` yet.
- Two files are **staged** (in the index, ready to commit): `src/auth.ts` (modified) and `src/oauth.ts` (brand new).
- Two things are **unstaged** but modified in the working tree: `src/auth.ts` has additional changes on top of the staged version, and `src/legacy.ts` has been deleted but the deletion isn't staged.
- One file is **untracked**: `tmp.log`, a log file that was never added to the repo.

The fact that `src/auth.ts` appears in both "staged" and "not staged" sections means you modified it, ran `git add`, then modified it again. The staged version and the working-tree version are different snapshots.

**To discard everything and get to a clean state:**

```
git reset --hard origin/feature/auth-v2
```

This will wipe all unstaged changes, unstage everything, and reset to where `origin/feature/auth-v2` currently sits. Your 2 local commits will still exist (but they'll be "orphaned" — accessible via `git reflog` if needed). The untracked `tmp.log` will remain; add `--orphan` or just delete it manually if you want that gone too.

## Working Directory State

**Branch position:** `feature/auth-v2` is 2 commits ahead of its remote tracking branch — those commits exist only locally and haven't been pushed.

**Staged changes (index):**
- `src/auth.ts` — modified and staged
- `src/oauth.ts` — new file, staged for the first time

**Unstaged changes (working tree):**
- `src/auth.ts` — also has *additional* modifications beyond what's staged (the file appears in both sections, meaning it was partially staged)
- `src/legacy.ts` — deleted in the working tree but that deletion isn't staged yet

**Untracked:**
- `tmp.log` — git has never tracked this file

---

## To Discard All Local Changes

"All local changes" is ambiguous here — it matters whether you also want to drop the 2 unpushed commits.

**If you want to keep the 2 unpushed commits but clear everything else** (staged, unstaged, and untracked):

```bash
git restore --staged .   # unstage everything
git restore .            # discard all working tree modifications
git clean -fd            # remove untracked files/dirs (tmp.log, etc.)
```

**If you want to wipe everything including the 2 unpushed commits** (reset to match the remote):

```bash
git fetch origin
git reset --hard origin/feature/auth-v2
git clean -fd
```

Note: `git reset --hard` is destructive and will permanently discard the 2 local commits. If there's any chance you want them later, push first or tag the current HEAD before resetting.

The app started normally, then degraded over time and finally crashed.

What happened:
1. Database and server came up fine.
2. A specific query got progressively slower: 2.1s, then 4.7s, then 8.2s.
3. Eventually all 20 DB connections were tied up.
4. Requests to `GET /api/user/.../events` began timing out after 30 seconds.
5. More pool exhaustion followed.
6. The server hit its fatal-error threshold and shut down.

Most likely root cause:
A database performance problem on the `SELECT * FROM events WHERE user_id = ?` query, most likely a missing or ineffective index on `events.user_id` or a sudden data growth causing that query to scan too much data.

Why that is the best explanation:
- The same query is explicitly called out as getting slower and slower.
- Pool exhaustion usually happens when queries hold connections too long.
- The timed-out requests are hitting the endpoint that likely runs that exact query.
- Nothing in the log suggests the database was down; it suggests it was too slow.

Possible secondary contributing causes:
- Connection leak in that endpoint, if connections were not returned to the pool.
- Traffic spike making a marginal query become catastrophic.

But from these lines alone, the most likely root cause is the slow `events by user_id` query exhausting the DB connection pool.

What happened, in order:

1. The app started normally (DB pool connected, server listening).
2. The same query got progressively slower over time:
   - 2.1s, then 4.7s, then 8.2s  
   (`SELECT * FROM events WHERE user_id = ?`)
3. Slow DB work tied up connections until the pool hit its max (20/20 in use).
4. Incoming API requests to `/api/user/.../events` waited on DB access and timed out at 30s.
5. Pool exhaustion/timeouts repeated, hit the app’s unrecoverable-error threshold, and triggered shutdown.

Most likely root cause:
A database bottleneck on that `events` lookup, most likely an unindexed (or ineffective) `user_id` filter on a growing table, compounded by a heavy `SELECT *`. That causes long-running queries, which saturate the connection pool, then cascades into request timeouts and process termination.

The log shows a cascading failure. Here's the sequence:

1. **Normal startup** — server connects to the DB pool and starts listening.
2. **Queries degrade** — roughly 30 minutes after startup, slow queries appear on `SELECT * FROM events WHERE user_id = ?`, with latency growing from 2.1s → 4.7s → 8.2s over about 25 minutes.
3. **Pool exhaustion** — connections are held long enough that all 20 are consumed.
4. **Timeouts and crash** — new requests queue, hit the 30s timeout, and the server ultimately shuts down after accumulating 5 unrecoverable errors.

**Most likely root cause:** The `events` table is missing an index on `user_id`. Without it, the query performs a full table scan. As the table grows over time (or as concurrent requests pile up), scan duration increases, connections are held longer, the pool saturates, and the server chokes. The progressive slowdown (2.1s → 8.2s) is the signature of a growing scan getting worse under load — not a sudden spike from a single bad query.

A secondary factor could be that the pool size (20) is undersized for the request volume, but the missing index is the primary culprit driving the cascade.

**What happened:**

The server started normally at 01:14:22. Approximately 33 minutes later, slow queries began appearing for the same operation — `SELECT * FROM events WHERE user_id = ?`. The query times grew progressively: 2.1s, then 4.7s, then 8.2s. This escalation consumed all 20 database connections as each slow query held a connection open for an increasingly long duration. With the pool exhausted, subsequent requests could not obtain connections. At 02:12:09 the pool first reported exhaustion, and requests began timing out after 30 seconds. By 02:13:45, after five unrecoverable errors, the server shut down.

**Root cause:**

The query `SELECT * FROM events WHERE user_id = ?` is performing a full table scan (likely because there is no index on `user_id`). As the `events` table grew, the scan took longer and longer, holding a connection open through each execution. With only 20 connections in the pool and slow queries consuming them progressively longer, the pool was saturated and new requests queued behind blocked connections until the server was overwhelmed.

The fix is to add an index on `user_id` in the `events` table, e.g.:
```sql
CREATE INDEX idx_events_user_id ON events(user_id);
```

**What happened**

The server started cleanly, then degraded over ~59 minutes into a fatal crash through a classic slow-query cascade:

1. **01:47–02:03** — The same query (`SELECT * FROM events WHERE user_id = ?`) begins timing out, with durations escalating sharply: 2.1s → 4.7s → 8.2s. This is not random noise; the progressive worsening over 16 minutes indicates growing pressure on the database.
2. **02:12** — Connection pool saturates. All 20 connections are held by long-running queries that haven't released yet.
3. **02:12–02:13** — Incoming requests queue for a connection, wait 30 seconds, then time out. The pool exhaustion event repeats, confirming connections are not being freed.
4. **02:13:45** — Five unrecoverable errors trigger the shutdown threshold and the process exits.

**Root cause**

The query `SELECT * FROM events WHERE user_id = ?` is almost certainly doing a full table scan because `events.user_id` lacks an index. As concurrent requests arrive, each one launches a long-running scan. Those scans hold database connections open for the duration. As the number of in-flight queries grows, the pool drains. Once exhausted, new requests block waiting for a free connection, which never comes — they time out instead, and the error count climbs to the fatal threshold.

The escalating query times (not flat — they grew from 2s to 8s) suggest the table is large and/or multiple concurrent scans were competing for I/O, making each successive query slower than the last.

**Fix**

Add an index on `events(user_id)`. That alone should drop the query from seconds to milliseconds and prevent pool exhaustion under normal load. You should also audit whether `SELECT *` is necessary — projecting only needed columns reduces I/O further — and consider whether the query needs a `LIMIT` if unbounded result sets are possible.

They are not semantically equivalent.

Differences:

1. `port` type differs.
   - YAML: `port: 5432` is a number.
   - JSON: `"port": "5432"` is a string.

2. That type difference may change behavior.
   - If a consumer expects a numeric port, the YAML value matches directly.
   - The JSON value may require coercion or may be rejected.

Everything else is equivalent in meaning:

- `database` object/key exists in both.
- `host` is `"localhost"` in both.
- `name` is `"helmdb"` in both.
- `options` is the same two-element list/array in the same order: `["ssl", "pooling"]`.
- `timeout` is the number `30` in both.
- Key order differs slightly, but for normal YAML/JSON object semantics that does not matter.

They are **not strictly semantically equivalent**.

Only meaningful difference in data is:

1. **`database.port` type differs**
   - YAML: `port: 5432` → number (integer)
   - JSON: `"port": "5432"` → string

Everything else matches semantically:
- `host` is `"localhost"` in both
- `name` is `"helmdb"` in both
- `options` is the same string array in the same order
- `timeout` is numeric `30` in both
- Key order differs, but object/map key order is not semantically significant in typical config parsing.

So equivalence depends on consumer behavior: with strict typing, **not equivalent**; with type coercion for `port`, they may behave the same.

No, they are not semantically equivalent. There is one substantive difference:

**Port field type:** In the YAML, `port: 5432` is an integer. In the JSON, `"port": "5432"` is a string. This is a type mismatch that could cause issues in systems expecting a numeric type.

The key ordering differs between the two (YAML places `port` before `name`; JSON places `name` before `port`), but JSON semantics do not consider order significant for object equality, so this has no practical effect.

Every other field is identical in both type and value across both representations.

No, they are not semantically equivalent. There is one difference:

**The `port` field has different types.**

In the YAML block, `port: 5432` is an unquoted integer. YAML parses it as the number 5432.

In the JSON block, `"port": "5432"` is a quoted string. JSON parses it as the string `"5432"`.

All other fields are effectively equivalent:

- `host` / `"host"`: both resolve to the string `localhost`
- `name` / `"name"`: both resolve to the string `helmdb`
- `timeout`: both resolve to the integer `30`
- `options`: both resolve to a list/array with elements `"ssl"` and `"pooling"`

The practical consequence is that downstream code reading `port` would receive a number type from the YAML but a string type from the JSON. Whether that matters depends on how the configuration consumer handles the value.

No, they are not semantically equivalent. There is one difference:

**`port` type mismatch**

- YAML: `port: 5432` — an integer
- JSON: `"port": "5432"` — a string (note the quotes)

Everything else is identical in value and type. The key ordering difference (YAML has `host, port, name`; JSON has `host, name, port`) is not a semantic difference, since neither format treats object key order as meaningful.

There are a few bugs, all from unquoted expansion.

What goes wrong:
1. `DIR=$1` is later used as `$DIR/*.tmp`, so paths with spaces get split.
2. `rm $f` is unquoted, so filenames with spaces, tabs, or glob characters break.
3. If the directory name starts with `-`, or a filename does, `rm` can treat it as an option.
4. If no `*.tmp` files exist, the loop may run once with the literal text `"$DIR/*.tmp"`.

Fixed version:

```bash
#!/bin/bash
dir=$1

for f in "$dir"/*.tmp; do
  [ -e "$f" ] || continue
  rm -- "$f"
done
```

A more robust version with argument checking:

```bash
#!/bin/bash
set -euo pipefail

dir=${1:?usage: $0 DIRECTORY}

[ -d "$dir" ] || {
  echo "Not a directory: $dir" >&2
  exit 1
}

for f in "$dir"/*.tmp; do
  [ -e "$f" ] || continue
  rm -- "$f"
done
```

If you want, I can also show a `find`-based version.

The bug is **unquoted expansion + glob edge cases**.

Problems in your script:

1. `for f in $DIR/*.tmp`  
   - If `DIR` has spaces, it splits into multiple words.
   - If `DIR` is empty, it becomes `/*.tmp` (dangerous).
   - If no `.tmp` files exist, Bash may pass the literal pattern (`/path/*.tmp`) to `rm`.

2. `rm $f`  
   - Unquoted filename can split/glob again.
   - Names starting with `-` can be treated as `rm` options.

Fixed version:

```bash
#!/usr/bin/env bash
set -euo pipefail

dir=${1:?Usage: $0 DIRECTORY}
[[ -d "$dir" ]] || { echo "Not a directory: $dir" >&2; exit 1; }

shopt -s nullglob
for f in "$dir"/*.tmp; do
  rm -- "$f"
done
```

This safely handles spaces, missing matches, and odd filenames.

# The Bug

The script has several related problems stemming from **unquoted variable expansion**. Word splitting and pathname expansion on unquoted `$DIR` and `$f` causes filenames with spaces or special characters to be parsed incorrectly.

**Concrete failure case:** a file named `hello world.tmp` becomes two arguments to `rm` — it deletes `hello` and tries to delete `world.tmp` as a separate file (likely failing), or worse, if `hello` happens to exist as a file, it gets deleted too.

**Secondary issues:**
- If `$DIR` is empty, the glob `*.tmp` runs in the current directory, silently doing the wrong thing.
- No check that `$DIR` is actually a directory.

# Fixed Version

```bash
#!/bin/bash
set -euo pipefail

DIR=${1:-}
if [[ -z "$DIR" ]]; then
  echo "Usage: $0 <directory>" >&2
  exit 1
fi
if [[ ! -d "$DIR" ]]; then
  echo "Error: $DIR is not a directory" >&2
  exit 1
fi

for f in "$DIR"/*.tmp; do
  [[ -e "$f" ]] && rm -- "$f"
done
```

**What each fix does:**

| Fix | Why |
|-----|-----|
| `set -euo pipefail` | Fails fast on errors and undefined variables |
| `${1:-}` with explicit check | Exits clearly if no argument given, instead of silently using `.` |
| `[[ ! -d "$DIR" ]]` | Refuses to run if the target isn't a directory |
| `"$DIR"/*.tmp` (quoted) | Prevents word splitting on the directory path |
| `rm -- "$f"` (quoted, with `--`) | Protects against filenames starting with `-` |
| `[[ -e "$f" ]] &&` | Handles `nullglob` edge case gracefully |

Several bugs:

1. **Unquoted variables** — Word-splitting and pathname expansion break on filenames with spaces or special characters. `DIR=/tmp/foo bar` becomes two words, and `rm $f` splits a file named `a.tmp b.tmp` into two separate arguments.

2. **No validation of `$1`** — If the argument is missing, empty, a non-existent path, or a file instead of a directory, behavior is undefined and likely destructive.

3. **Bare `rm $f` without `--`** — A filename like `-rf` is treated as a flag, not a file to delete.

4. **Glob may not expand** — If `nullglob` is off and no `*.tmp` files exist, the pattern passes literally (e.g., `/missing/*.tmp`), and `rm` tries to delete a file literally named `*.tmp`.

5. **No error reporting** — The script silently succeeds even when it does the wrong thing.

Fixed version:

```bash
#!/bin/bash
set -euo pipefail

DIR="${1:-}"

if [[ -z "$DIR" ]]; then
  echo "Usage: $0 <directory>" >&2
  exit 1
fi

if [[ ! -d "$DIR" ]]; then
  echo "Error: '$DIR' is not a directory" >&2
  exit 1
fi

shopt -s nullglob
for f in "$DIR"/*.tmp; do
  rm -- "$f"
done
```

Key changes: double-quotes around all variable expansions, `set -euo pipefail` for fail-fast behavior, a `--` separator in `rm` to stop option parsing, `nullglob` so a non-matching glob becomes empty rather than a literal string, and input validation before any side effects.

Three bugs:

**1. Unquoted `$DIR` and `$f`** — word splitting means any path or filename containing spaces gets split into multiple tokens. `rm $f` on a file named `my file.tmp` runs `rm my file.tmp`, trying to delete two separate paths.

**2. No `nullglob` handling** — when no `.tmp` files exist, the glob `$DIR/*.tmp` doesn't expand; bash passes the literal string to `rm`. That causes an error at best, or deletes a file literally named `*.tmp` at worst.

**3. No argument check** — if `$1` is empty, `DIR` is empty and the glob becomes `/*.tmp`, operating on the filesystem root rather than failing loudly.

Fixed version:

```bash
#!/bin/bash
DIR="${1:?Usage: $0 <directory>}"
shopt -s nullglob
for f in "$DIR"/*.tmp; do
  rm -- "$f"
done
```

Changes:
- `"${1:?...}"` aborts with a usage message if no argument is given
- `shopt -s nullglob` makes the glob expand to nothing (skipping the loop) when there are no matches
- `"$f"` and `"$DIR"` quoted throughout to handle spaces in paths/filenames
- `--` before `$f` prevents filenames starting with `-` from being interpreted as flags

If you want a simpler one-liner that's equally correct:

```bash
#!/bin/bash
DIR="${1:?Usage: $0 <directory>}"
find "$DIR" -maxdepth 1 -name '*.tmp' -delete
```

The `find` version also avoids the glob issue entirely and is safer with unusual filenames.

It means the server understood the request, expected a Bearer access token, and rejected it because that token is expired.

What it tells you:
- `401 Unauthorized`: authentication failed
- `WWW-Authenticate: Bearer ...`: this endpoint uses Bearer token auth
- `error="invalid_token"` with `error_description="The access token expired"`: the presented access token is no longer valid because it expired

What the client should do:
- Stop retrying the same expired access token
- Obtain a fresh access token, typically by using a refresh token or re-authenticating
- Retry the API request with the new access token
- If refresh fails, treat the user session as expired and prompt sign-in again

In short: this is an auth renewal problem, not a malformed request or permission problem.

This response is very specific:

1. `401 Unauthorized` means authentication failed for this request.
2. `WWW-Authenticate: Bearer ... error="invalid_token"` says the bearer token is not usable.
3. `error_description="The access token expired"` gives the exact reason: the token is expired (not malformed, not missing scope).

What the client should do:

1. Stop retrying with the same access token.
2. Get a new access token:
   - Prefer refresh-token flow (if available).
   - Otherwise re-authenticate the user.
3. Retry the original API request with the new token.
4. If refresh fails (invalid/expired refresh token), force full sign-in.
5. Optionally improve client behavior by refreshing slightly before expiry and checking clock skew.

The response tells you the following:

**What it means:**
- The server received a Bearer token in the `Authorization` header, but that token has expired.
- The `WWW-Authenticate` header is an OAuth 2.0 challenge, indicating this is a Bearer token authentication scheme.
- The error code `invalid_token` with the specific description `"The access token expired"` means what it says — the token is no longer valid.

**What the client should do:**

1. **Detect the 401 with an expired token response.** The client should recognize the `invalid_token` / `token expired` condition.

2. **Use the refresh token to obtain a new access token**, if the client holds a refresh token. It should POST to the token endpoint with `grant_type=refresh_token` and the refresh token value.

3. **Retry the original request** with the new access token.

4. **If no refresh token is available**, the client must re-authenticate the user from scratch (e.g., redirect to a login page or initiate the authorization code flow).

A typical refresh token exchange looks like:

```
POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=<refresh_token>&client_id=<client_id>
```

If the refresh token is also expired or revoked, the server will return a different error (e.g., `invalid_grant`), in which case the user must re-authenticate.

The key signal here is `WWW-Authenticate: Bearer ... error="invalid_token" ... error_description="The access token expired"`. That is the server telling the client exactly why it was rejected and roughly how to fix it.

This is a standard OAuth 2.0 Bearer token authentication failure. Here's what it tells you and what to do:

**What it tells you:**

- The request included an `Authorization: Bearer <token>` header.
- The API validated the token but found it has passed its expiration time.
- The token is structurally valid (not malformed, not revoked, not a wrong secret) — it simply expired.
- The `WWW-Authenticate` header with `realm="api"` and `error="invalid_token"` follows RFC 6750, the standard for Bearer token errors.

**What the client should do:**

1. **Do not retry the request as-is.** Re-sending the same expired token will keep returning 401.
2. **Attempt to refresh the token.** If your app stores a refresh token alongside the access token, use it to obtain a new access token from your authorization server's token endpoint. Refresh tokens have longer lifetimes and are designed for this exact situation.
3. **If refresh succeeds:** retry the original request with the new access token.
4. **If refresh fails or is not available:** the user needs to re-authenticate (log in again) to get a new access token.

**In short:** The client should detect the 401 with `error="invalid_token"` and `error_description="The access token expired"`, then invoke its token refresh flow. Only after obtaining a fresh access token should it retry the API request.

The response tells you the client presented a valid, well-formed bearer token, but it has passed its expiration time. The server recognized and parsed the token — it didn't reject it as malformed or unauthorized by identity — it specifically expired.

**What the client should do:**

1. **Refresh the access token.** If the client holds a refresh token (OAuth 2.0 flow), it should exchange it with the authorization server's token endpoint for a new access token, then retry the original request with the new token.

2. **If no refresh token exists**, the client must re-authenticate from scratch (redirect the user to login, re-run the client credentials flow, etc.).

3. **Retry the original request** with the new access token in the `Authorization: Bearer <new_token>` header.

**What the client should not do:**

- Retry the same request with the same token — it's expired and won't suddenly become valid.
- Treat this as a permissions error. A 403 would mean the token is valid but lacks access. A 401 with `invalid_token` and this description is purely a freshness problem.

**Preventively**, a well-behaved client should track the token's `expires_in` value from when it was issued and proactively refresh before expiry, rather than waiting for a 401 to discover it's stale. Most OAuth libraries handle this automatically.

The function is correct for typical numeric inputs.

What it does:
- Raises `ValueError` on an empty input, which is appropriate.
- Sorts the input before computing the median.
- Returns the middle element for odd-length inputs.
- Returns the average of the two middle elements for even-length inputs.

Potential caveats, but not bugs in the usual sense:
- If `numbers` contains non-numeric values, or values that cannot be sorted/added/divided together consistently, it can fail.
- For some numeric types, the `/ 2` may change the return type, for example `int` inputs can produce a `float` for even-length lists.

So, no bug in the core median logic.

No logic bug in the median calculation itself.

It correctly:
- raises on empty input,
- sorts,
- returns middle element for odd length,
- returns average of the two middle elements for even length.

Only caveats (not logic bugs unless your requirements differ):
- It assumes elements are sortable and add/divide like numbers.
- For even-length integer inputs, result is a `float` (because of `/ 2`).

The function is correct. It handles all standard cases properly:

- **Empty sequence**: raises `ValueError` as expected.
- **Odd length**: returns the middle element (index `n // 2`).
- **Even length**: returns the average of the two middle elements (`sorted_nums[mid - 1]` and `sorted_nums[mid]`), which is the conventional median definition.

No bugs.

This function is correct. Let me trace through the logic:

For an empty list, it raises `ValueError` as expected.

For odd-length lists (e.g., `[1, 2, 3, 4, 5]`):
- `n = 5`, `mid = 2`, `n % 2 == 1`
- Returns `sorted_nums[2]` = `3`, the middle element. Correct.

For even-length lists (e.g., `[1, 2, 3, 4]`):
- `n = 4`, `mid = 2`, `n % 2 == 0`
- Returns `(sorted_nums[1] + sorted_nums[2]) / 2` = `(2 + 3) / 2` = `2.5`, the average of the two middle elements. Correct.

The indexing is sound: for even `n`, `mid` points to the right-side middle element, so `mid - 1` correctly identifies the left-side middle. No bugs detected.

No bugs. The function is correct.

- Empty input raises `ValueError` — appropriate guard.
- Sorts a copy via `sorted()` — doesn't mutate the input.
- Odd-length: returns the middle element at index `n // 2` — correct.
- Even-length: averages the two middle elements at `mid - 1` and `mid` — correct.
- Division uses `/` (not `//`), so the even-length average is a float — correct behavior for a median.