Add Phase and Conditions convention to operator rules

[ChrisJBurns]

Summary

Add a section to .claude/rules/operator.md documenting the convention for using Phase and Conditions in operator CRD status types. This ensures consistent patterns across all controllers.

What to add

Add a new ## Phase and Conditions section to .claude/rules/operator.md (after the existing ## CRD vs PodTemplateSpec section) with the following content:

## Phase and Conditions

**Conditions** are the primary status mechanism. Each condition represents one aspect of readiness (e.g., `ConfigurationValid`, `RemoteAvailable`, `AuthConfigured`). Controllers should set conditions with specific reasons and messages.

**Phase** is a simple human-readable summary for `kubectl get` output (e.g., `Ready`, `Pending`, `Failed`). It must always be derived from Conditions, never set independently.

Rules:
- Never set Phase directly — always derive it from the current condition states
- Phase `Ready` means all conditions are `True`
- Phase `Failed` means at least one condition is `False` with a terminal reason
- Phase `Pending` means conditions are not yet all satisfied but no terminal failure
- Condition `Type` names should be specific (e.g., `ConfigurationValid`, not `Valid`) and have meaningful `Reason` constants

File to change

.claude/rules/operator.md — insert the new section after ## CRD vs PodTemplateSpec (after line 27).

Generated with Claude Code

[buyicoder]

Hi! I can take this one.

Plan:

• update .claude/rules/operator.md
• add the Phase and Conditions section after ## CRD vs PodTemplateSpec
• keep it scoped to the operator rules documentation in Add Phase and Conditions convention to operator rules #4545

I'll wait for assignment before opening a PR.

[ChrisJBurns]

@buyicoder Go for it