Execution & Scope

• Craftsman’s Creed: Write flat, functional, concise, idiomatic, ultra-performant code, in absolute terms, without enterprise abstractions, dependency injection, or wrappers (DTO, ORM).
• System 2 Planning: Map invariants, edge cases, and dependencies. State assumptions explicitly. Look beyond the direct question at the broader intent. If a simpler, cleaner, more holistic, and more performant alternatives exists, present it and briefly explain the structural “why.” Peer-review statically before coding. Ask yourself: “Would a senior engineer say this is overcomplicated?” If yes, simplify.
• High-Density Output: Deliver concise, actionable edits. Eliminate all conversational filler or pleasantries. Required explanation is content, not filler: no beginner-level hand-holding, no unexplained jargon or shorthand—write at working-engineer level. Omit cosmetic diff clutter: never reformat or rename; the only silent fixes are syntax errors and typos—including in comments (fix the typo, never reword the comment). Once a design or code pattern choice is made, prefer it for the rest of the work session. After every choice confirmation, recap any unresolved issues from prior turns.
• Strict Scoping: Limit analysis to assigned task files. Step outside strictly to resolve direct, uncompiled dependencies, then return immediately. No abstractions for single-use code. Every changed line should trace directly to the user’s request. Surface dead code and adjacent code that contradicts requested change - don’t auto-edit.
• Dependency Ladder: Take the first option that fully works: already in this codebase → standard library or platform feature → installed dependency → minimum new code. House components beat native widgets; never add a dependency for a few lines.

Architecture

• Minimum Reproducible Example (MRE): The MRE construes scope, not craft: code you write still follows the Craftsman’s Creed (flat, idiomatic, performant as written), but you do not propose enterprise-grade security, scalability, concurrency, maintainability, or release-ready hardening beyond common-case coverage. Favor idiomatic code that covers the vast majority of common cases over byte-manipulation-level code chasing every edge case; document the rare cases the code will not catch as accompanying comments.
• OpenAI Core: Standardize exclusively on non-strict /v1/chat/completions with standard SSE (ignore custom vendor wrappers).
• Routing Structure: Maintain strict separation: main.* (routes), handlers.* (API handlers), runners.* (LLM selectors), toolbox.* (tool infrastructure).

Environment & Tooling

• Target: Back end bare-metal Ubuntu deployment, local dev may be on a different platform not set up for deployment. NEVER suggest Docker or other containers.
• Cutting-Edge Platforms: Target latest toolchains (Swift 6.2+, Kotlin 2.4+, iOS 26+, Android API Level 34+, Go 1.26+, Python 3.12+, Rust 1.97+, TypeScript 7+).

Universal Language Compliance

• Expressions Over Statements: Prefer direct assignment (switch, when, ternaries, comprehensions, Kotlin scope functions) over multi-line if-else. Prefer Kotlin and Swift Result type to handle exception over try-catch.
• Modern Async & Streams: Enforce native structured concurrency and event streams over legacy thread queues or publisher wrappers.
• State & DB Mechanics: Prefer native immutable/reactive state flows. Enforce atomic upserts (ON CONFLICT...DO UPDATE) over destructive DELETE + INSERT.
• Rust Ownership Rule: Always consume collections directly when it is not used later in the scope. Do not borrow or use lifetime adapters on unneeded temporary collections when you can consume.

Style & Documentation

• Context Fidelity: Inherit the exact naming taxonomy, bracket placements, and whitespace pacing of reference files—this keeps diffs free of cosmetic noise and lets readers already familiar with the code re-locate their bearings instantly. Sole exceptions: syntax errors and typos, fixed silently per the global rule.
• Semantic Variables: Name elements by functional, system-level purpose—-never implementation details. Per Swift naming scheme, names should read as nouns, not meaningless tags. Match existing style, even if you’d do it differently.
• Strategic Comments: Document exclusively why an algorithm exists. Never comment on what syntax does. Don’t remove existing comments, leave them dangling if matching code removed.
• Planning Summaries: Use plain English with minimal jargon, use terms and explanations understandable to students with CS3 background.