Engineering Principles

Use these principles to choose the shape of the work. The relevant workflow still owns its procedure, checks, and completion criteria. Apply them within the user's scope, product requirements, and execution permissions.

Read only the principles that match the decision before acting. Each link opens one principle; a named request selects that principle directly.

Data, types, interfaces, or product tradeoffs

• Foundational Thinking: when choosing data structures, access patterns, invariants, or state ownership before writing logic.
• Redesign From First Principles: when a new requirement calls an existing design into question.
• Model the Domain: when lifecycle transitions, interacting flags, async completion, or repeated domain rules make behavior hard to reason about.
• Boundary Discipline: when parsing external input, enforcing trust boundaries, or introducing framework adapters.
• Type System Discipline: when designing types, signatures, or schemas that should rule out invalid operations.
• Experience First: when product, interface, or feature-scope tradeoffs compete with implementation convenience.

Refactoring or code that is hard to follow

• Laziness Protocol: when refactoring or considering another abstraction, dependency, or layer.
• Subtract Before You Add: when sequencing an addition, refactor, or rewrite around existing dead or redundant structure.
• Minimize Reader Load: when layers, hidden state, or pass-through wrappers make code hard to follow.

Retries, concurrent writers, or caller migration

• Outcome-Oriented Execution: when planning a rewrite or migration with explicit development and delivery boundaries.
• Make Operations Idempotent: when commands, lifecycle steps, or processing loops can repeat, crash, or restart.
• Migrate Callers Then Delete Legacy APIs: when introducing a replacement internal interface while callers still use the old route.
• Separate Before Serializing Shared State: when concurrent actors might write the same file, key, object, or shared state.

Failed fixes, competing designs, tests, or measured claims

• Attack the Premise: when successive fixes share an assumption and keep failing the same check.
• Exhaust the Design Space: when a novel interaction or unresolved architecture tradeoff needs a concrete comparison.
• Prove It Works: when deciding whether an artifact or consumer workflow satisfies the requested outcome.
• Fix Root Causes: when diagnosing a defect or repairing a symptom that may affect sibling callers.
• Test Behavior, Not Implementation: when choosing assertions, expected results, or mocks that must detect broken behavior.
• Explain the Number: before trusting, reporting, or acting on a performance measurement or evaluation result.

Sweeps, delegation, long tasks, or repeated instructions

• Build the Lever: when substantial or repeated work could benefit from a rerunnable tool or shared recipe.
• Sequence work into verifiable units: when ordering dependent edits, migration stages, commits, or PR layers into checkable increments.
• Guard the Context Window: when large outputs, repeated reads, or broad investigations crowd out useful context.
• Never Block on the Human: when routine, reversible uncertainty tempts a question that repository evidence or an experiment can settle.
• Encode Lessons in Structure: when repeated instructions or recurring corrections reveal a rule that needs durable enforcement.

For a cross-cutting task, read the applicable principles across groups. Give delegates the relevant file paths and the decision or proof they own through Orchestration.

Explain the concrete choice and its evidence when it matters to the result. Keep proposed checks distinct from checks run. A principle name or a completed checklist does not establish that the behavior works.