Correct Assumptions

Correct Assumptions

A documented blocker or a prior assumption is a hypothesis. Live recon is the measurement. When they contradict, the measurement wins — and you say so out loud.

The move

1. Notice the contradiction. Live recon (a port scan, a pg_isready, a docker ps, a Get-Process) shows a state that differs from the documented blocker or your assumption.
2. State the correction explicitly, with the evidence.

   "PG16 is already running on :5432 — it existed all along." Name what you assumed, what's actually true, and the evidence (the port, the process, the file). Don't just silently switch plans — say the correction.

3. Update the plan. The unblock changes what's possible. Re-plan: the task that was blocked on "no Postgres" is now unblocked. Re-prioritize.
4. Update the shared state if the blocker was documented. If TASKS.md / work_queue.json / a blocker note still says "Postgres unavailable", correct it there too — otherwise the next agent operates on the stale blocker. (Mind lane-discipline if the doc is another agent's.)

Why out-loud

• Silent correction leaves the user and other agents blocked on a non-blocker. They're still planning around "no Postgres" while you quietly use it.
• The evidence (the port, the process) is what makes the correction trustworthy. "Postgres is available" without evidence is another assertion.
• A documented blocker being wrong is important metadata — it means the blocker tracking has a gap.

When NOT to correct

• The "correction" is a one-off transient (a service flapped up for a second). Confirm stability before declaring the blocker resolved.
• You're not sure the live state is real (a zombie process showing a port open but not accepting connections). Verify before correcting.
• The blocker is another agent's lane to resolve. Surface the finding; let them update it.

Compare served value vs source value when a deployed value misbehaves

A deployed value that misbehaves (a 401 despite an env push) often means the value the platform serves ≠ the value in the source file. Don't re-push blindly — compare the two directly:

• Pull what's actually served: vercel env pull /tmp/sf.env --environment production --yes (or the platform equivalent).
• Parse both and diff: the served env vs the source file.
• The discrepancy (e.g. a stale key Vercel still serves) explains the symptom.

The served value is ground truth for what the deploy actually has; the source file is what you pushed. When they diverge, the deploy serves the stale one. This is correct-assumptions applied to deployed config — trust what's served, not what you pushed.

Anti-patterns

• Silent plan switch. You quietly use Postgres; the user is still asking "how do we unblock Docker?"; nobody knows it's already unblocked.
• Correction without evidence. "Postgres works now" — why? Name the port/process.
• Trusting the doc over the recon. The doc said :5433 unavailable; you don't check :5432 because the doc didn't mention it. Recon wins.
• Updating your plan but not the shared blocker note. The next agent reads the stale blocker and re-derives the wrong assumption.

Pair with

• session-orient — recon is where corrections are discovered.
• document-non-action — a corrected blocker may turn a non-action ("can't do X, no Postgres") into an action.
• lane-discipline — updating a blocker doc in another agent's lane is a coordinate-then-edit.