Corrections Policy

What qualifies for correction

Incorrect commands, broken paths, misleading security statements, and outdated assumptions that can block successful execution.

• Command syntax that fails in documented baseline environments.
• Dependency/version notes that no longer reflect observed behavior.
• Incorrect risk labels or missing rollback instructions.

Response timeline

We triage reports quickly and prioritize security-impacting issues first. Critical fixes are applied as soon as they are reproduced.

Typical ordering: critical security issues (same day when reproducible), broken core install flows (1-3 days), and non-blocking clarity fixes (scheduled in normal update cycles).

Change disclosure

Meaningful corrections are documented in article update sections and reflected in `lastmod` metadata where applicable.

How to report a correction

Include page URL, observed command output, your runtime context (OS/shell/tool versions), and expected behavior. Reproducible reports are resolved faster and help us avoid introducing secondary regressions.

Historical transparency

We avoid silent rewrites for material technical changes. When fixes alter user outcomes, we add clear update notes so readers can understand what changed and why.