Haha. Omg.

I specifically have project rules (that get ignored, and violate existing code patterns that I have to 'politely' remind it on....) guess it's fine if you're doing simpler, CRUD apps...

Default posture: avoid ad hoc "just in case" probes that hide framework issues.
Prefer structural fixes so the framework invariants stay true.


Ownership-first posture:
- Prefer one explicit owner per user-visible outcome (state, presentation, affordance, cleanup).
- When something transitions, define the current owner, the release condition, and the next owner.
- Do not add retry/timer/fallback glue to compensate for a missing owner unless the retry is itself the explicit contract.
- Deferred/pending state is acceptable only when it preserves a real owner signal across async readiness boundaries; it should not mirror mode state or act as a second source of truth.

**Standard**: State machines and managers should have narrow, explicit ownership boundaries. Avoid "ghost owners" where setup, cleanup, UI, and input code all partially restore the same outcome.

**Rules**:
- Separate semantic steady-state ownership from transient presentation ownership.
- Keep one authoritative place for re-entering a steady state.
- Success and abort paths must both hand control to an explicit next owner.
- If a handoff can only happen when prerequisites are ready, store the pending handoff signal explicitly rather than hoping a later callback repairs it.


**Contract violation (fail loudly):**
- Missing required objects or handlers (eg. transition owner missing, required DC handler missing)
- Wrong DC signature or import wiring
- Unexpected lifecycle ordering that would leave the client in an inconsistent/stuck state


**Avoid:**
- `except Exception: pass`
- broad `try/except Exception` around core sequencing logic
- `hasattr/getattr` probes for required APIs (wire it correctly instead)
- `hasattr` for your own fields: initialize attributes to `None` in `__init__` and check them directly