fastify/.pi/self-learning-memory/daily/2026-08-04.md

Fast and low overhead web framework, for Node.js

## 10:59 UTC — Task

### What went wrong
- Assumed /static/..%2f… 404 meant getPathnameForSend/route miss instead of later send pipeline behavior
- Did not check that encodeURI() re-encodes residual % as %25 before blaming path guards
- Conflated reply.callNotFound() JSON ("Route GET:… not found") with an actual find-my-way miss
- Debugged isolated getPathnameForSend reimplementation before tracing pumpSendToReply → encodeURI(pathnameForSend) → @fastify/send
- Compared send() on decoded ../ paths (403) to static outcomes without using the exact post-encodeURI string static passes

### How it was fixed
- Always log/compare the exact pathname string passed into send(), including after encodeURI
- When statuses differ for "same" path, diff charCodes for % vs %25 double-encoding first
- Instrument static handler vs router to separate callNotFound from unmatched routes
- Trace full pipeline: raw.url → getPathnameForSend → dotDot guards → encodeURI → @fastify/send
- Reproduce with send(root, p) using both raw and encodeURI(p) before changing triage conclusions

## 11:12 UTC — Task

### What went wrong
- Assumed encodeURI leaves '%' intact on paths like '/..%2ftop-secret.txt', so static 404 vs raw '..' 403 looked inconsistent.
- Treated encoded traversal and decoded param sinks as the same layer before separating find-my-way dual-decode from @fastify/send root checks.
- Relied on log/message shape alone (callNotFound 'Route ... not found') to infer static failure mode without probing @fastify/send inputs.

### How it was fixed
- Empirically print encodeURI output/charCodes: '%' → '%25', so static sees '/..%252ftop-secret.txt' (safe 404) not a '..' segment.
- Reproduce with @fastify/send directly for raw percent, encodeURI(percent), and decoded '../' to map 403 vs 404 to normalize/root logic.
- Keep reporter response framed as app-level path.join(param) misuse; cite static/sendFile containment and Express parity, not a core CVE.

## 12:31 UTC — Task

### What went wrong
- Markdown lint invoked in a way that flooded output with unrelated files (AGENTS.md, .pi memory, response.md) instead of only the two edited docs.
- Untracked response.md sat in the working tree and could have been staged if git add was too broad.
- Relied on noisy repo-wide lint signal before confirming MD013 on the actual changed regions.

### How it was fixed
- Re-run markdownlint scoped strictly to docs/Reference/Request.md and docs/Reference/Routes.md.
- Stage only those two paths (git add docs/Reference/Request.md docs/Reference/Routes.md); never git add .
- Manually awk length>80 on changed files to confirm new lines stay ≤80 before commit.
- Leave response.md untracked and verify git status/diff --stat before commit and PR.