When updating documentation, ensure every statement about requirements, capabilities, and behavior is (1) correct for the current implementation, (2) explicit about when the requirement matters (e.g., render-time vs apply-time vs run-time), (3) consistent across related doc artifacts, and (4) does not imply unsupported configuration paths. Follow house style for headings/navigation (e.g., tab names).

How to apply:

• Check “point of impact” phrasing: state prerequisites at the moment they affect the user’s workflow.
• Remove stale/changelog/README prose that no longer matches current guards/behavior; reword to match actual enforcement.
• Keep duplicated sections in sync (if the repo uses byte-identical entries, update all copies identically).
• Don’t add documentation for features that the schema/product doesn’t support (avoid implying a config.json mechanism when it isn’t available).
• Match house style for UI labels and section/tab names.

Example (pattern to follow when prerequisites only matter at apply-time):

• Good: “Set serviceMonitor.enabled: true to render a ServiceMonitor targeting the http service port. The monitoring.coreos.com/v1 CRDs must be present when the manifest is applied; rendering itself does not require them.”
• Avoid: “CRDs are required to render,” if rendering succeeds without them.