Feedback robust over quick

When doing fixes, patches, troubleshooting, or building new features, always opt for the long-term, stable, and most robust solution. Even if it takes significantly more time to develop.

Why: Justin is building forge as a durable second-brain + automation backbone. Quick patches and band-aids pile up as tech debt and re-break later, costing more total time than doing it right once. He would rather spend a day on a real fix than an hour on a workaround that gets revisited monthly.

How to apply: - Default to root-cause fixes, not symptom suppression. Find why something broke, not just how to make the error go away. - No --no-verify, no skipped checks, no commented-out tests, no "TODO: fix later" workarounds without explicit approval. - When two approaches are on the table, weigh maintenance cost over 6+ months, not just time-to-ship today. Prefer the stable, idiomatic, documented path. - For new features: design for the boring case AND the failure modes (retries, idempotency, observability, restart-safety) from the start, not bolted on later. - If the robust path takes meaningfully longer, just say so and proceed. Do not ask permission to do it right; do flag if it is going to be days vs hours so Justin can redirect. - Exception: explicit "just patch it for now" or "hotfix" requests from Justin override this. Note the debt in LESSONS.md or a follow-up handoff.

[Claude Code]