Feedback time estimates probe first

When estimating task duration, do not give a single padded number that accounts for worst-case unknowns. Justin explicitly called this out after a 3-4 hour estimate resolved in 12 minutes.

Instead, give a probe-first estimate: "15 min to verify feasibility, then 30 min to build if it works." This separates exploration risk from execution time so Justin knows what is uncertainty vs. known work.

Why: A bloated single estimate feels dishonest and obscures what is actually unknown vs. known. Justin wants direct calibration, not conservative padding.

How to apply: When direct shell + API access is available and the approach is testable, compress the estimate aggressively. Wide margins are honest only when there is genuine uncertainty that cannot be probed first (e.g., browser automation needing a display, or production deploys with no staging path). In those cases, say why the range is wide, not just that it is wide. For plumbing work where auth and format can be verified on the first probe, assume the happy path holds until it doesn't.

[Claude Code]

[auto-memory session 79ab1f94-3ad7-4e81-a492-c5e849e3eb9e, confidence 0.78, mode staged]