Effective Engineering
Choose the route for the system or code decision, then read the references
needed to resolve it. Use repository contracts and observed requirements;
do not require a full architecture review for a local change.
Prefer the simplest design supported by evidence. Add abstractions, fallback
states, or tests for reachable, consequential behavior; weigh their maintenance
cost. Preserve security, privacy, authorization, money, and data-integrity
boundaries even when failures are rare. Do not invent scale or reliability
requirements.
Keep types, ownership, asynchronous work, and failure behavior explicit.
Validate changed contracts at a faithful boundary; performance claims need a
representative measurement. Continue through the authorized implementation and
report material uncertainty without expanding into speculative hardening.
Route by Intent
| User intent |
Read |
| Assess, design, review, or evolve system boundaries, responsibilities, quality attributes, operational readiness, or testing strategy |
Software Architecture |
| Design or review a public HTTP, GraphQL, event, or library boundary: request and response shape, validation, error semantics, compatibility, retry safety, or consumer impact |
API and Interface Contracts |
| Decide data models, datastores, transactions, consistency, replication, partitioning, streams, schema evolution, or migrations |
Data Systems |
| Write or review server-side and shared-library TypeScript: types, narrowing, module and package API, async, cancellation, typed errors, tsconfig |
TypeScript Engineering |
| Write or review Rust: ownership, borrowing, public API, naming, errors, panics, concurrency, cancellation |
Rust Engineering |
| Change Rust crate or module structure, public interfaces, domain types, persistence, or async boundaries |
Rust Architecture |
| Make a Rust runtime, build-time, binary-size, or profiling claim; choose collections, allocation, layout, boxing, or integer widths |
Rust Performance and Memory |
| Write or review Rust unsafe blocks, raw pointers, FFI or ABI boundaries, SIMD, target features, atomics, Rayon, or thread pools |
Rust Unsafe and SIMD |
| Protect a behavior, invariant, regression, failure path, retry, authorization rule, migration, or CLI contract; diagnose a flaky or undiscovered test |
Focused Testing |
| Design, repair, or interpret a microbenchmark, comparative benchmark, or bounded end-to-end performance workflow |
Benchmark Methodology |
Routing Boundaries
effective-web: browser-facing TypeScript, React, frontend architecture,
performance, and all frontend test design and diagnosis. Route by the outcome;
pure logic inside a browser feature does not make it a backend task.effective-delivery: repository audits, implementation plans, ports, PR
review and upkeep, dependency updates, running established checks, technical
documentation, and team workflows. Supply language-depth findings as needed.effective-product: product direction and durable decisions recorded as ADRs.effective-marketing: positioning and public performance or reliability claims.effective-writing: articles and explainers about the engineering work.
New load, soak, and stress methodology is outside this collection. Escalate
specialist security, regulatory, infrastructure, or production-operations
choices when evidence and authority cannot establish a safe direction.
1---2name: effective-engineering3description: Design software architecture, APIs, data models, transactions, and migrations; write or review Rust and server-side or shared-library TypeScript; design focused non-frontend tests and benchmarks. Use for system and code contracts. Browser implementation and frontend tests belong to effective-web; repository audits, ports, PR upkeep, dependency upgrades, and running existing checks belong to effective-delivery.4---56# Effective Engineering78Choose the route for the system or code decision, then read the references9needed to resolve it. Use repository contracts and observed requirements;10do not require a full architecture review for a local change.1112Prefer the simplest design supported by evidence. Add abstractions, fallback13states, or tests for reachable, consequential behavior; weigh their maintenance14cost. Preserve security, privacy, authorization, money, and data-integrity15boundaries even when failures are rare. Do not invent scale or reliability16requirements.1718Keep types, ownership, asynchronous work, and failure behavior explicit.19Validate changed contracts at a faithful boundary; performance claims need a20representative measurement. Continue through the authorized implementation and21report material uncertainty without expanding into speculative hardening.2223## Route by Intent2425| User intent | Read |26| --- | --- |27| Assess, design, review, or evolve system boundaries, responsibilities, quality attributes, operational readiness, or testing strategy | [Software Architecture](references/route-architecture.md) |28| Design or review a public HTTP, GraphQL, event, or library boundary: request and response shape, validation, error semantics, compatibility, retry safety, or consumer impact | [API and Interface Contracts](references/route-api-contracts.md) |29| Decide data models, datastores, transactions, consistency, replication, partitioning, streams, schema evolution, or migrations | [Data Systems](references/route-data.md) |30| Write or review server-side and shared-library TypeScript: types, narrowing, module and package API, async, cancellation, typed errors, tsconfig | [TypeScript Engineering](references/route-typescript.md) |31| Write or review Rust: ownership, borrowing, public API, naming, errors, panics, concurrency, cancellation | [Rust Engineering](references/route-rust.md) |32| Change Rust crate or module structure, public interfaces, domain types, persistence, or async boundaries | [Rust Architecture](references/route-rust-architecture.md) |33| Make a Rust runtime, build-time, binary-size, or profiling claim; choose collections, allocation, layout, boxing, or integer widths | [Rust Performance and Memory](references/route-rust-performance.md) |34| Write or review Rust unsafe blocks, raw pointers, FFI or ABI boundaries, SIMD, target features, atomics, Rayon, or thread pools | [Rust Unsafe and SIMD](references/route-rust-unsafe.md) |35| Protect a behavior, invariant, regression, failure path, retry, authorization rule, migration, or CLI contract; diagnose a flaky or undiscovered test | [Focused Testing](references/route-testing.md) |36| Design, repair, or interpret a microbenchmark, comparative benchmark, or bounded end-to-end performance workflow | [Benchmark Methodology](references/route-benchmarks.md) |3738## Routing Boundaries3940- `effective-web`: browser-facing TypeScript, React, frontend architecture,41 performance, and all frontend test design and diagnosis. Route by the outcome;42 pure logic inside a browser feature does not make it a backend task.43- `effective-delivery`: repository audits, implementation plans, ports, PR44 review and upkeep, dependency updates, running established checks, technical45 documentation, and team workflows. Supply language-depth findings as needed.46- `effective-product`: product direction and durable decisions recorded as ADRs.47- `effective-marketing`: positioning and public performance or reliability claims.48- `effective-writing`: articles and explainers about the engineering work.4950New load, soak, and stress methodology is outside this collection. Escalate51specialist security, regulatory, infrastructure, or production-operations52choices when evidence and authority cannot establish a safe direction.
sebastian-software