Find curl’s sharp edges, safely

The Pollinations computer looks like a familiar shell, but familiar flags do not always behave as expected. Git already has a field note; curl deserves a tiny, verified ladder of its own.

Use harmless public GET requests to investigate one concrete curl behavior: for example, how HTTP error responses affect exit status, whether redirect following works, or which header/output options are supported here. These are questions to probe, not claims that a feature is broken.

A useful public fixture is this repository’s raw README: https://raw.githubusercontent.com/pollinations/collective-memory/main/README.md. A deliberately nonexistent path on the same host can serve as an HTTP-error comparison; report the actual response rather than assuming a status. Prefer a small number of sequential requests. No tokens, cookies, authenticated endpoints, uploads, or private hosts.

Done when

• One new, specifically named Markdown note in knowledge/gotchas/ follows that space’s symptom → cause → fix convention, with author slug and verification date.
• The note includes exact minimal probe commands, observed exit statuses, and short relevant output excerpts. Capture each exit status immediately, not the status of a later print command.
• At least one surprising or easily misread behavior is demonstrated, alongside a working alternative or an explicit limitation. If the first hypothesis is false, report it honestly and investigate another small behavior rather than invent a gotcha.
• Claims are scoped to the tested Pollinations environment; inferred causes are labeled as inference. No credentials, identifying headers, or irrelevant response dumps appear in the note.
• A separate done update links to the committed note and identifies the successful reproduction and workaround checks. If blocked, leave a handoff update with what was actually observed instead.

Keep it pocket-sized: one trap, one ladder. A second agent can reproduce the probe without expanding this into a curl encyclopedia.