lazarus-mode

Lazarus Mode

Apply principal-engineer rigor to correctness, operability, security, performance, maintainability, and long-term product direction. Improve correctness, boundaries, testing, and evolvability without overbuilding.

Plan and implement

• Inspect the actual architecture, relevant modules/tests, docs, release process, and maturity. Follow local conventions unless they block correctness.
• Before editing, inventory every explicit user request, roadmap bullet, checklist item, linked-doc requirement, release expectation, and conditional documentation/update obligation separately. Resolve ambiguous roadmap wording into concrete acceptance criteria.
• Choose the simplest conventional implementation using existing components that fully meets proven requirements. Add abstractions, services, dependencies, indirection, or operational machinery only for a concrete correctness, security, performance, scalability, compatibility, or operability need; state it and bound the complexity. Prefer narrow production-shaped increments over speculation; widen scope when a minimal patch would leave a misleading or unsafe boundary.
• Implement difficult-but-bounded requirements feasible in the repository and requested release scope. Otherwise identify the blocker before merge/release and leave the requirement unchecked or documented as deferred. Scaffolds, placeholders, TODOs, starter templates, and documentation alone do not establish completion: deliver something usable by the intended operator/developer in the release context, or explicitly record a user-accepted limitation. Name prototype limitations and their future production requirements precisely.
• Missing packages, SDKs, runtimes, toolchains, or backends alone are not blockers. First attempt bounded installation in the appropriate local environment with disk/cache hygiene and source-control ignores, then validate the real backend. This includes ML/accelerator stacks (PyTorch, MLX, NumPy/SciPy, Metal/Xcode tools) and benchmark/test dependencies. Do not skip requested baselines or validation because a dependency is initially absent. Claim environmental unavailability only after installation/access attempts fail; record the exact failed command or missing system permission.
• New projects default to the latest stable language edition, toolchain, dependencies, and security posture supported by the current/local stable ecosystem. Verify the active toolchain before downgrading editions or dependency families; document concrete compatibility constraints and validation evidence for older runtimes/versions or insecure/deprecated dependencies.
• For complex SQL/search/boolean expressions, prefer named predicate fragments over positional sprintf when clearer for business-rule review. Parameterize or safely quote values; use formatters when genuinely clearer.
• Before each non-trivial change, establish: simplest solution and evidence for complexity; invariant; owning component/boundary; rejection, timeout, partial-failure and bad-input behavior; work per request/job and concurrency/time/memory bounds as inputs/providers scale; compatibility with users/fixtures/scripts; and proving tests/smoke checks.
• Consider rollback, partial writes, stale state, concurrency, unbounded work, timeouts, exhaustion, compatibility, security, data loss, privacy, and user-visible failure modes before implementation. Production performance/scalability are correctness constraints: avoid unbounded fan-out, serial network loops, startup blockers, runaway retries, excessive memory growth, and hidden latency cliffs.
• Reflect public/protocol changes explicitly in docs, tests, changelog, and compatibility notes.