| 1 | # Engineering Reading Digest v1 |
| 2 | |
| 3 | **Legacy.** Каноническая база знаний — `kb-engineering-evidence-v1.md` (записи по темам). Этот файл сохранён как архив выписок по батчам. |
| 4 | |
| 5 | ## Purpose |
| 6 | Accumulated distilled notes from completed reading with direct applicability to .NET engineering work. |
| 7 | |
| 8 | ## Entry Template |
| 9 | - Source: |
| 10 | - Date: |
| 11 | - Fact: |
| 12 | - Heuristic: |
| 13 | - First adoption task: |
| 14 | - Success criterion: |
| 15 | - Confidence: |
| 16 | |
| 17 | ## Batch 01 (Completed): Platform Baseline |
| 18 | |
| 19 | ### Entry 01 |
| 20 | - Source: Microsoft Learn - What's new in C# 14 (`https://learn.microsoft.com/dotnet/csharp/whats-new/csharp-14`) |
| 21 | - Date: 2026-02-25 |
| 22 | - Fact: C# 14 introduces extension members, null-conditional assignment, field-backed properties, enhanced span conversions, and partial constructors/events. |
| 23 | - Heuristic: treat language features as selective leverage; adopt only where they reduce complexity or runtime overhead in active code. |
| 24 | - First adoption task: evaluate `field`-backed property and null-conditional assignment opportunities in actively edited domain models/view models. |
| 25 | - Success criterion: reduced boilerplate without added ambiguity in code review. |
| 26 | - Confidence: medium |
| 27 | |
| 28 | ### Entry 02 |
| 29 | - Source: Microsoft Learn - C# language versioning (`https://learn.microsoft.com/dotnet/csharp/language-reference/language-versioning`) |
| 30 | - Date: 2026-02-25 |
| 31 | - Fact: C# 14 is supported on .NET 10+; compiler defaults are TFM-aligned; using newer-than-TFM language combinations is unsupported. |
| 32 | - Heuristic: keep language policy deterministic and framework-compatible to avoid machine-specific breakage. |
| 33 | - First adoption task: verify solution-wide TFM and LangVersion policy in shared build config. |
| 34 | - Success criterion: no unsupported language/runtime combinations across projects. |
| 35 | - Confidence: high |
| 36 | |
| 37 | ### Entry 03 |
| 38 | - Source: Microsoft Learn - What's new in .NET 10 (`https://learn.microsoft.com/dotnet/core/whats-new/dotnet-10/overview`) |
| 39 | - Date: 2026-02-25 |
| 40 | - Fact: .NET 10 (LTS) includes runtime, SDK, testing platform, and libraries improvements relevant to performance and delivery workflows. |
| 41 | - Heuristic: upgrade decisions should be driven by measurable gains (build/test/debug/latency), not by novelty. |
| 42 | - First adoption task: define a small before/after benchmark set for representative workloads. |
| 43 | - Success criterion: evidence-backed upgrade value on local project metrics. |
| 44 | - Confidence: medium |
| 45 | |
| 46 | ### Entry 04 |
| 47 | - Source: Microsoft Learn - Unit testing best practices for .NET (`https://learn.microsoft.com/dotnet/core/testing/unit-testing-best-practices`) |
| 48 | - Date: 2026-02-25 |
| 49 | - Fact: resilient tests are fast, isolated, repeatable, and readable; avoid infrastructure in unit tests; prefer AAA and one Act per test. |
| 50 | - Heuristic: test quality is constrained more by design and readability than by raw coverage percentage. |
| 51 | - First adoption task: enforce naming/AAA/one-Act conventions in newly added tests and refactor flaky patterns. |
| 52 | - Success criterion: lower flaky test rate and faster root-cause detection in CI/local runs. |
| 53 | - Confidence: high |
| 54 | |
| 55 | ## Queue (Next Sources) |
| 56 | - C# in Depth (Skeet) - language semantics and hidden sharp edges. |
| 57 | - Pro .NET Memory Management (Kokosa) - GC and allocation strategy. |
| 58 | - xUnit Test Patterns (Meszaros) - test smell catalog and remediation. |
| 59 | - Working Effectively with Legacy Code (Feathers) - seam-first recovery strategy. |
| 60 | - Designing Data-Intensive Applications (Kleppmann) - data-system tradeoffs. |
| 61 | |
| 62 | ## Batch 02 (Completed): Test and Diagnostics Foundations |
| 63 | |
| 64 | ### Entry 05 |
| 65 | - Source: Microsoft Learn - Integration tests in ASP.NET Core (`https://learn.microsoft.com/aspnet/core/test/integration-tests?view=aspnetcore-10.0`) |
| 66 | - Date: 2026-02-25 |
| 67 | - Fact: integration tests should cover critical infrastructure boundaries (DB/files/network/request pipeline), while broad permutation coverage remains in unit tests for speed. |
| 68 | - Heuristic: reserve integration tests for high-risk seams and use `WebApplicationFactory` + `TestServer` as the standard host pattern. |
| 69 | - First adoption task: define a minimal integration suite for critical HTTP flows, persistence boundary, and auth boundary. |
| 70 | - Success criterion: critical path regressions are caught without major slowdown in feedback cycle. |
| 71 | - Confidence: high |
| 72 | |
| 73 | ### Entry 06 |
| 74 | - Source: Microsoft Learn - .NET diagnostic tools overview (`https://learn.microsoft.com/dotnet/core/diagnostics/tools-overview`) |
| 75 | - Date: 2026-02-25 |
| 76 | - Fact: first-line diagnosis should start with counters/stacks/traces (`dotnet-counters`, `dotnet-stack`, `dotnet-trace`) before deep dump analysis. |
| 77 | - Heuristic: use staged diagnostics escalation (health signals -> trace -> dump) to reduce time-to-root-cause. |
| 78 | - First adoption task: create a lightweight diagnostics runbook mapping common symptoms to first tool choice. |
| 79 | - Success criterion: lower mean time to identify root cause in CPU/memory/thread incidents. |
| 80 | - Confidence: high |
| 81 | |
| 82 | ### Entry 07 |
| 83 | - Source: Microsoft Learn - Testing with `dotnet test` (`https://learn.microsoft.com/dotnet/core/testing/unit-testing-with-dotnet-test`) |
| 84 | - Date: 2026-02-25 |
| 85 | - Fact: .NET 10 introduces Microsoft.Testing.Platform mode for `dotnet test`; mixed VSTest/MTP usage is discouraged. |
| 86 | - Heuristic: keep one consistent test runner model solution-wide to avoid silent option mismatches and unsupported configurations. |
| 87 | - First adoption task: decide and document single runner mode for active solutions (`global.json` + shared props policy). |
| 88 | - Success criterion: deterministic local/CI test behavior without mode-dependent surprises. |
| 89 | - Confidence: medium |
| 90 | |
| 91 | ### Entry 08 |
| 92 | - Source: xUnit docs via Context7 (`/xunit/xunit.net`) - shared context and fixtures guidance |
| 93 | - Date: 2026-02-25 |
| 94 | - Fact: xUnit creates a new test class instance per test; shared setup should use fixtures (`IClassFixture`, `ICollectionFixture`, assembly fixtures) deliberately. |
| 95 | - Heuristic: default to isolated tests and introduce shared fixtures only for expensive immutable context. |
| 96 | - First adoption task: audit existing test classes for hidden shared mutable state and migrate to explicit fixture patterns where needed. |
| 97 | - Success criterion: reduced flakiness and clearer test lifecycle semantics. |
| 98 | - Confidence: high |
| 99 | |
| 100 | ## Batch 03 (Completed): Async and Web Reliability |
| 101 | |
| 102 | ### Entry 09 |
| 103 | - Source: Microsoft Learn - ASP.NET Core Best Practices (`https://learn.microsoft.com/aspnet/core/fundamentals/best-practices?view=aspnetcore-10.0`) |
| 104 | - Date: 2026-02-25 |
| 105 | - Fact: reliability and throughput depend on async end-to-end paths, avoiding sync-over-async, reducing LOH pressure, and keeping hot paths minimal. |
| 106 | - Heuristic: treat thread-pool starvation and allocation spikes as first-class regressions, not incidental performance noise. |
| 107 | - First adoption task: create a concise checklist for controller/middleware reviews (async I/O, pagination, HttpClientFactory, no captured HttpContext in background tasks). |
| 108 | - Success criterion: fewer starvation-related incidents and lower p95 latency variance. |
| 109 | - Confidence: high |
| 110 | |
| 111 | ### Entry 10 |
| 112 | - Source: Microsoft Learn - Asynchronous programming scenarios (`https://learn.microsoft.com/dotnet/csharp/asynchronous-programming/async-scenarios`) |
| 113 | - Date: 2026-02-25 |
| 114 | - Fact: choose async strategy by workload type (I/O-bound vs CPU-bound), use `Task.WhenAll/WhenAny`, avoid blocking waits (`Wait/Result`), and force immediate LINQ task materialization (`ToArray/ToList`). |
| 115 | - Heuristic: async correctness is mostly about preserving non-blocking flow and explicit concurrency boundaries. |
| 116 | - First adoption task: audit existing async code for blocking calls and deferred LINQ task pitfalls. |
| 117 | - Success criterion: no deadlock-prone patterns in newly touched modules. |
| 118 | - Confidence: high |
| 119 | |
| 120 | ### Entry 11 |
| 121 | - Source: Microsoft Learn - EventCounters tutorial (`https://learn.microsoft.com/dotnet/core/diagnostics/event-counter-perf`) |
| 122 | - Date: 2026-02-25 |
| 123 | - Fact: low-overhead operational telemetry can be established with `EventSource/EventCounter` plus `dotnet-counters monitor/collect`. |
| 124 | - Heuristic: instrument first, optimize second; track trend over time instead of single-point snapshots. |
| 125 | - First adoption task: define a minimal counter set for active services (`requests/sec`, request latency metric, `cpu-usage`) and capture baseline traces. |
| 126 | - Success criterion: at least one reproducible before/after performance baseline per optimization cycle. |
| 127 | - Confidence: medium |
| 128 | |
| 129 | ## Batch 04 (Completed): Platform Evolution and Data Layer |
| 130 | |
| 131 | ### Entry 12 |
| 132 | - Source: Microsoft Learn - What's new in .NET 10 runtime (`https://learn.microsoft.com/dotnet/core/whats-new/dotnet-10/runtime`) |
| 133 | - Date: 2026-02-25 |
| 134 | - Fact: .NET 10 runtime improves JIT codegen/inlining/devirtualization, broadens stack allocation scenarios, and reduces abstraction overhead in common patterns. |
| 135 | - Heuristic: performance work should prioritize shape-friendly code that the JIT can optimize (tight loops, predictable allocations, clear call paths). |
| 136 | - First adoption task: identify one hot path and test whether minor code-shape changes produce measurable JIT wins in Release mode. |
| 137 | - Success criterion: observable CPU or latency improvement with no semantic regression. |
| 138 | - Confidence: medium |
| 139 | |
| 140 | ### Entry 13 |
| 141 | - Source: Microsoft Learn - What's new in ASP.NET Core 10 (`https://learn.microsoft.com/aspnet/core/release-notes/aspnetcore-10.0?view=aspnetcore-10.0`) |
| 142 | - Date: 2026-02-25 |
| 143 | - Fact: ASP.NET Core 10 introduces meaningful behavior changes (for example, streaming defaults in some client paths) and template/runtime-level UX/security updates. |
| 144 | - Heuristic: release upgrades require explicit audit of behavioral defaults, not only API compilation success. |
| 145 | - First adoption task: create upgrade checklist item for runtime behavior deltas impacting networking/streaming/security-sensitive flows. |
| 146 | - Success criterion: no unexpected post-upgrade runtime behavior in critical scenarios. |
| 147 | - Confidence: medium |
| 148 | |
| 149 | ### Entry 14 |
| 150 | - Source: Microsoft Learn - What's new in EF Core 10 (`https://learn.microsoft.com/ef/core/what-is-new/ef-core-10.0/whatsnew`) |
| 151 | - Date: 2026-02-25 |
| 152 | - Fact: EF Core 10 adds major capabilities (JSON/vector support, named filters, richer translation controls, improved bulk update ergonomics) and updates SQL generation strategies. |
| 153 | - Heuristic: treat ORM upgrades as query-planning events; verify generated SQL and plan behavior on representative workloads. |
| 154 | - First adoption task: select 2-3 high-impact queries and compare generated SQL/plans before and after EF10 adoption. |
| 155 | - Success criterion: neutral or improved query stability and performance under production-like data shapes. |
| 156 | - Confidence: medium |
| 157 | |
| 158 | ### Entry 15 |
| 159 | - Source: Microsoft Learn - Microsoft.Testing.Platform intro (`https://learn.microsoft.com/dotnet/core/testing/microsoft-testing-platform-intro`) |
| 160 | - Date: 2026-02-25 |
| 161 | - Fact: MTP emphasizes deterministic, hostable, low-dependency test execution and aligns with .NET 10 `dotnet test` evolution. |
| 162 | - Heuristic: prefer one deterministic test execution model per repo to avoid mode split and inconsistent tooling behavior. |
| 163 | - First adoption task: define repository-wide test runner stance and codify it in `global.json` + shared test project policy. |
| 164 | - Success criterion: identical local and CI test semantics for the same commit. |
| 165 | - Confidence: high |
| 166 | |
| 167 | ### Entry 16 |
| 168 | - Source: Microsoft Learn - C# language versioning + C# 14 (`https://learn.microsoft.com/dotnet/csharp/language-reference/language-versioning`, `https://learn.microsoft.com/dotnet/csharp/whats-new/csharp-14`) |
| 169 | - Date: 2026-02-25 |
| 170 | - Fact: C# 14 support is bound to .NET 10+ targets; mismatched language/runtime combinations are unsupported and risk subtle failures. |
| 171 | - Heuristic: pin language-policy by TFM and avoid machine-dependent compiler behavior for shared codebases. |
| 172 | - First adoption task: validate that active projects target `.NET 10` where C# 14 features are expected, and enforce explicit fallback for older targets. |
| 173 | - Success criterion: no unsupported language-version combinations in build matrix. |
| 174 | - Confidence: high |
| 175 | |
| 176 | ### Entry 17 |
| 177 | - Source: Microsoft Learn - Testing with `dotnet test` in .NET 10 (`https://learn.microsoft.com/dotnet/core/testing/unit-testing-with-dotnet-test`) |
| 178 | - Date: 2026-02-25 |
| 179 | - Fact: .NET 10 differentiates VSTest mode and MTP mode with concrete migration steps; mixed assumptions can silently ignore options. |
| 180 | - Heuristic: command-line compatibility must be treated as contract and verified in CI scripts after runner migration. |
| 181 | - First adoption task: add CI smoke command set that validates expected test runner options and exit behavior. |
| 182 | - Success criterion: no silently ignored critical test arguments in CI. |
| 183 | - Confidence: medium |
| 184 | |
| 185 | ## Batch 05 (Completed): Perf Diagnostics and Query Efficiency |
| 186 | |
| 187 | ### Entry 18 |
| 188 | - Source: Microsoft Learn - Debug high CPU usage (`https://learn.microsoft.com/dotnet/core/diagnostics/debug-highcpu`) |
| 189 | - Date: 2026-02-25 |
| 190 | - Fact: high-CPU investigation is most effective with staged workflow: verify counters, capture trace, inspect call stacks/hot methods. |
| 191 | - Heuristic: always separate symptom confirmation (`dotnet-counters`) from causal analysis (`dotnet-trace` + stack/call-tree tools). |
| 192 | - First adoption task: standardize a high-CPU playbook for active services with fixed capture duration and artifact naming. |
| 193 | - Success criterion: repeatable hotspot identification in one diagnostic cycle. |
| 194 | - Confidence: high |
| 195 | |
| 196 | ### Entry 19 |
| 197 | - Source: Microsoft Learn - Debug a memory leak (`https://learn.microsoft.com/dotnet/core/diagnostics/debug-memory-leak`) |
| 198 | - Date: 2026-02-25 |
| 199 | - Fact: leak diagnosis requires both growth confirmation over time and heap root analysis from dumps, not only working-set observation. |
| 200 | - Heuristic: use object-root chains (`gcroot`) to find ownership leaks rather than guessing from type counts alone. |
| 201 | - First adoption task: add memory-leak checklist (baseline -> load -> counters -> dump -> root analysis). |
| 202 | - Success criterion: identified retaining owner for major leaked object classes. |
| 203 | - Confidence: high |
| 204 | |
| 205 | ### Entry 20 |
| 206 | - Source: Microsoft Learn - Debug ThreadPool starvation (`https://learn.microsoft.com/dotnet/core/diagnostics/debug-threadpool-starvation`) |
| 207 | - Date: 2026-02-25 |
| 208 | - Fact: starvation is strongly indicated by sustained thread count growth with low CPU saturation and blocking stacks on ThreadPool workers. |
| 209 | - Heuristic: treat sync-over-async (`.Result/.Wait`) as critical risk in request paths and enforce async end-to-end. |
| 210 | - First adoption task: run static/targeted audit for blocking waits in request handlers and service hot paths. |
| 211 | - Success criterion: no blocking wait pattern in newly changed high-traffic paths. |
| 212 | - Confidence: high |
| 213 | |
| 214 | ### Entry 21 |
| 215 | - Source: Microsoft Learn - dotnet-trace utility (`https://learn.microsoft.com/dotnet/core/diagnostics/dotnet-trace`) |
| 216 | - Date: 2026-02-25 |
| 217 | - Fact: `dotnet-trace` provides cross-platform EventPipe-based traces with tunable providers/profiles and controlled duration for production-safe capture. |
| 218 | - Heuristic: keep trace collection scope narrow (providers + duration) to reduce noise and dropped events. |
| 219 | - First adoption task: define default trace presets for CPU, contention, and GC investigations. |
| 220 | - Success criterion: actionable traces with low event-loss and clear analysis target. |
| 221 | - Confidence: medium |
| 222 | |
| 223 | ### Entry 22 |
| 224 | - Source: Microsoft Learn - Unit testing code coverage (`https://learn.microsoft.com/dotnet/core/testing/unit-testing-code-coverage`) |
| 225 | - Date: 2026-02-25 |
| 226 | - Fact: coverage metrics are useful as feedback signals but not as standalone quality proxy; tooling should feed branch-level insight into review workflow. |
| 227 | - Heuristic: optimize for meaningful test behavior coverage, not maximal percentage. |
| 228 | - First adoption task: publish baseline coverage report generation path (`coverlet` + report generator) for CI/local parity. |
| 229 | - Success criterion: stable and readable coverage artifacts per test run. |
| 230 | - Confidence: medium |
| 231 | |
| 232 | ### Entry 23 |
| 233 | - Source: Microsoft Learn - EF Core efficient querying (`https://learn.microsoft.com/ef/core/performance/efficient-querying`) |
| 234 | - Date: 2026-02-25 |
| 235 | - Fact: major EF perf wins come from indexing alignment, selective projection, controlled result size, eager/split loading strategy, and tracking-mode choice. |
| 236 | - Heuristic: query performance is primarily data-shape and SQL-plan driven; ORM API choices should be evaluated by generated SQL and execution plans. |
| 237 | - First adoption task: audit top read queries for over-projection, missing pagination, and unnecessary tracking. |
| 238 | - Success criterion: reduced query latency and allocation for selected hot queries. |
| 239 | - Confidence: high |
| 240 | |
| 241 | ## Batch 06 (Completed): Architecture and Testing Methodology |
| 242 | |
| 243 | ### Entry 24 |
| 244 | - Source: Refactoring.Guru - Code Smells (`https://refactoring.guru/refactoring/smells`) |
| 245 | - Date: 2026-02-25 |
| 246 | - Fact: smell taxonomy (bloaters, couplers, dispensables, change preventers, OOP abusers) provides a practical lens for refactoring prioritization. |
| 247 | - Heuristic: classify before changing; choose refactoring moves by smell class rather than ad-hoc stylistic edits. |
| 248 | - First adoption task: add lightweight PR-review smell tags (`duplicate code`, `long method`, `feature envy`, `shotgun surgery`) for changed files. |
| 249 | - Success criterion: recurring refactoring decisions become faster and more consistent. |
| 250 | - Confidence: medium |
| 251 | |
| 252 | ### Entry 25 |
| 253 | - Source: Refactoring.Guru - Design Patterns Catalog (`https://refactoring.guru/design-patterns/catalog`) |
| 254 | - Date: 2026-02-25 |
| 255 | - Fact: pattern selection remains most effective when mapped to change pressure (creation flexibility, composition constraints, behavior variability). |
| 256 | - Heuristic: treat patterns as response to concrete forces, not as architecture defaults. |
| 257 | - First adoption task: for each new abstraction, require one-sentence force statement before introducing a pattern. |
| 258 | - Success criterion: lower accidental complexity from unnecessary abstractions. |
| 259 | - Confidence: medium |
| 260 | |
| 261 | ### Entry 26 |
| 262 | - Source: Martin Fowler - Patterns of Enterprise Application Architecture catalog (`https://martinfowler.com/eaaCatalog/`) |
| 263 | - Date: 2026-02-25 |
| 264 | - Fact: enterprise systems benefit from explicit pattern choices around domain logic, mapping, transactional boundaries, and integration seams. |
| 265 | - Heuristic: make data-access and domain-boundary patterns explicit in architecture docs to avoid hidden coupling drift. |
| 266 | - First adoption task: map current persistence strategy to EAA vocabulary (`Repository`, `Unit of Work`, `Data Mapper`) and document intent. |
| 267 | - Success criterion: clearer architectural communication and fewer contradictory implementations. |
| 268 | - Confidence: high |
| 269 | |
| 270 | ### Entry 27 |
| 271 | - Source: Martin Fowler - The Practical Test Pyramid (`https://martinfowler.com/articles/practical-test-pyramid.html`) |
| 272 | - Date: 2026-02-25 |
| 273 | - Fact: effective test portfolios prioritize many fast low-level tests, fewer integration tests, and very limited end-to-end tests. |
| 274 | - Heuristic: optimize for feedback speed and maintainability; avoid test-suite shape drift toward slow end-to-end-heavy layers. |
| 275 | - First adoption task: categorize existing tests by pyramid layer and identify overrepresented expensive layers. |
| 276 | - Success criterion: reduced end-to-end dependence and faster median CI cycle. |
| 277 | - Confidence: high |
| 278 | |
| 279 | ### Entry 28 |
| 280 | - Source: Martin Fowler - CQRS (`https://martinfowler.com/bliki/CQRS.html`) |
| 281 | - Date: 2026-02-25 |
| 282 | - Fact: CQRS is situational; it can help in complex/high-scale bounded contexts but often introduces harmful complexity when applied broadly. |
| 283 | - Heuristic: apply CQRS only where read/write model divergence is proven by domain or scaling constraints. |
| 284 | - First adoption task: introduce architecture decision check requiring explicit bounded-context and complexity tradeoff when proposing CQRS. |
| 285 | - Success criterion: fewer premature split-model designs with weak justification. |
| 286 | - Confidence: high |
| 287 | |
| 288 | ### Entry 29 |
| 289 | - Source: Twelve-Factor App (`https://12factor.net/`) |
| 290 | - Date: 2026-02-25 |
| 291 | - Fact: deployment resilience and portability improve with strict config separation, stateless processes, and dev/prod parity discipline. |
| 292 | - Heuristic: delivery robustness should be encoded into runtime/process contracts, not left to operator convention. |
| 293 | - First adoption task: evaluate active services against 12-factor checklist and log highest-risk gaps. |
| 294 | - Success criterion: reduced environment-specific failures across local/stage/prod. |
| 295 | - Confidence: medium |
| 296 | |
| 297 | ## Batch 07 (Completed): Data and Resilience Infrastructure |
| 298 | |
| 299 | ### Entry 30 |
| 300 | - Source: PostgreSQL docs - Index introduction (`https://www.postgresql.org/docs/current/indexes-intro.html`) |
| 301 | - Date: 2026-02-25 |
| 302 | - Fact: index value comes from selectivity and planner statistics; indexing adds write overhead and must be justified by query workload. |
| 303 | - Heuristic: treat every index as a read/write tradeoff decision with maintenance cost. |
| 304 | - First adoption task: inventory frequently used indexes and remove low-value prefixes/duplicates. |
| 305 | - Success criterion: stable or improved query latency with no unnecessary index maintenance burden. |
| 306 | - Confidence: high |
| 307 | |
| 308 | ### Entry 31 |
| 309 | - Source: PostgreSQL docs - Using EXPLAIN (`https://www.postgresql.org/docs/current/using-explain.html`) |
| 310 | - Date: 2026-02-25 |
| 311 | - Fact: plan analysis requires comparing estimates vs actuals (`EXPLAIN ANALYZE`) and understanding join/scan node composition. |
| 312 | - Heuristic: SQL tuning should begin with plan literacy, not blind query rewrites. |
| 313 | - First adoption task: introduce plan-review template for critical queries (node type, row estimate error, dominant cost). |
| 314 | - Success criterion: faster root-cause isolation for slow query incidents. |
| 315 | - Confidence: high |
| 316 | |
| 317 | ### Entry 32 |
| 318 | - Source: SQLite docs - Query planner (`https://sqlite.org/queryplanner.html`) |
| 319 | - Date: 2026-02-25 |
| 320 | - Fact: multi-column and covering indexes materially reduce lookup/sort cost; index order strongly shapes planner effectiveness. |
| 321 | - Heuristic: index design must mirror real filter and ordering patterns. |
| 322 | - First adoption task: validate that mobile/embedded query patterns align with left-prefix and covering-index opportunities. |
| 323 | - Success criterion: lower scan/sort overhead in representative SQLite workloads. |
| 324 | - Confidence: medium |
| 325 | |
| 326 | ### Entry 33 |
| 327 | - Source: Redis docs - Diagnosing latency (`https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/latency/`) |
| 328 | - Date: 2026-02-25 |
| 329 | - Fact: Redis latency spikes often originate from environment/OS constraints (intrinsic latency, THP, fork, swap, slow commands), not Redis core command cost alone. |
| 330 | - Heuristic: troubleshoot from infrastructure baseline upward before optimizing command-level logic. |
| 331 | - First adoption task: create Redis latency checklist (intrinsic latency, slowlog, THP, fork time, swap, AOF/fsync profile). |
| 332 | - Success criterion: quicker discrimination between infra-induced and workload-induced latency. |
| 333 | - Confidence: high |
| 334 | |
| 335 | ### Entry 34 |
| 336 | - Source: Azure Architecture Center - CQRS pattern (`https://learn.microsoft.com/azure/architecture/patterns/cqrs`) |
| 337 | - Date: 2026-02-25 |
| 338 | - Fact: CQRS can improve scalability and boundary clarity but introduces synchronization and eventual-consistency complexity. |
| 339 | - Heuristic: adopt CQRS only with clear asymmetry in read/write requirements or explicit bounded-context complexity. |
| 340 | - First adoption task: require ADR section for consistency model and synchronization strategy in CQRS proposals. |
| 341 | - Success criterion: fewer architecture reversals caused by underestimated complexity. |
| 342 | - Confidence: high |
| 343 | |
| 344 | ### Entry 35 |
| 345 | - Source: Azure Architecture Center - Retry pattern (`https://learn.microsoft.com/azure/architecture/patterns/retry`) |
| 346 | - Date: 2026-02-25 |
| 347 | - Fact: robust retries depend on transient-fault classification, backoff strategy, idempotency guarantees, and bounded attempts. |
| 348 | - Heuristic: retries are reliability controls, not universal error handling. |
| 349 | - First adoption task: define per-dependency retry profiles (attempts, backoff, timeout, circuit-breaker interplay). |
| 350 | - Success criterion: fewer cascading failures and reduced tail-latency amplification under partial outages. |
| 351 | - Confidence: high |
| 352 | |
| 353 | ## Batch 08 (Completed): Agile Architecture and Fault Isolation |
| 354 | |
| 355 | ### Entry 36 |
| 356 | - Source: Microsoft Learn - Architectural principles (`https://learn.microsoft.com/dotnet/architecture/modern-web-apps-azure/architectural-principles`) |
| 357 | - Date: 2026-02-25 |
| 358 | - Fact: maintainable systems consistently rely on separation of concerns, encapsulation, dependency inversion, explicit dependencies, and bounded contexts. |
| 359 | - Heuristic: architecture quality improves when dependencies point toward abstractions and domain logic remains isolated from infrastructure/UI. |
| 360 | - First adoption task: add architecture review checklist for new modules (SoC, DIP, explicit dependencies, bounded context boundary). |
| 361 | - Success criterion: fewer cross-layer leaks and easier testability of business logic. |
| 362 | - Confidence: high |
| 363 | |
| 364 | ### Entry 37 |
| 365 | - Source: Microsoft Learn - Domain model validations (`https://learn.microsoft.com/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-model-layer-validations`) |
| 366 | - Date: 2026-02-25 |
| 367 | - Fact: aggregate/domain invariants must be enforced in domain behavior, not delegated only to UI binding or persistence metadata. |
| 368 | - Heuristic: domain entities should be invalid-state resistant by construction and mutation methods. |
| 369 | - First adoption task: review aggregate roots for invariant enforcement in constructors/mutators and close annotation-only validation gaps. |
| 370 | - Success criterion: invalid domain state cannot be persisted through normal code paths. |
| 371 | - Confidence: high |
| 372 | |
| 373 | ### Entry 38 |
| 374 | - Source: Azure Architecture Center - Circuit Breaker (`https://learn.microsoft.com/azure/architecture/patterns/circuit-breaker`) |
| 375 | - Date: 2026-02-25 |
| 376 | - Fact: circuit breakers mitigate persistent or slow-recovery dependencies through closed/open/half-open state transitions and controlled probes. |
| 377 | - Heuristic: retries should be bounded by breaker state; fallback behavior must be explicit for degraded mode. |
| 378 | - First adoption task: define breaker policy per critical dependency (trip threshold, open duration, half-open probe count, fallback contract). |
| 379 | - Success criterion: reduced cascading failure during dependency outages. |
| 380 | - Confidence: high |
| 381 | |
| 382 | ### Entry 39 |
| 383 | - Source: Martin Fowler - Unit Test (`https://martinfowler.com/bliki/UnitTest.html`) |
| 384 | - Date: 2026-02-25 |
| 385 | - Fact: unit tests are fundamentally about fast feedback on small scopes; sociable vs solitary style is contextual, but speed and frequency are key. |
| 386 | - Heuristic: tune test suites for feedback cadence (compile suite and commit suite) rather than ideological purity. |
| 387 | - First adoption task: define runtime budget targets for local and CI test suites and classify tests by intended feedback loop. |
| 388 | - Success criterion: developers run tests frequently without friction and detect regressions earlier. |
| 389 | - Confidence: high |
| 390 | |
| 391 | ### Entry 40 |
| 392 | - Source: Martin Fowler - Mocks Aren't Stubs (`https://martinfowler.com/articles/mocksArentStubs.html`) |
| 393 | - Date: 2026-02-25 |
| 394 | - Fact: behavior-verification mocks and state-verification doubles serve different purposes; misuse increases coupling or obscures failures. |
| 395 | - Heuristic: choose doubles intentionally by collaboration risk (determinism, speed, boundary awkwardness), not by framework habit. |
| 396 | - First adoption task: add test review guidance distinguishing mock/stub/fake usage and expected verification mode. |
| 397 | - Success criterion: lower test brittleness and clearer failure diagnostics. |
| 398 | - Confidence: medium |
| 399 | |
| 400 | ### Entry 41 |
| 401 | - Source: Martin Fowler - YAGNI (`https://martinfowler.com/bliki/Yagni.html`) |
| 402 | - Date: 2026-02-25 |
| 403 | - Fact: speculative features impose build cost, delay cost, and carry cost; only malleable codebases can safely defer features. |
| 404 | - Heuristic: avoid presumptive abstractions unless immediate value is clear and complexity is near-zero. |
| 405 | - First adoption task: require explicit justification for "future-proofing" code in PRs/ADRs. |
| 406 | - Success criterion: reduced accidental complexity and faster delivery of current-value features. |
| 407 | - Confidence: high |
| 408 | |
| 409 | ## Batch 09 (Completed): Algorithmic Depth, Reliability, and Security Baselines |
| 410 | |
| 411 | ### Entry 42 |
| 412 | - Source: Sedgewick/Wayne Algorithms, 4th edition site (`https://algs4.cs.princeton.edu/home/`) |
| 413 | - Date: 2026-02-25 |
| 414 | - Fact: practical algorithm competence depends on fluency across core chapters: fundamentals, sorting, searching, graphs, strings, and context-driven applications. |
| 415 | - Heuristic: treat DS/A as an operational toolkit; map each production bottleneck to one or two candidate algorithm families before optimizing code. |
| 416 | - First adoption task: add "algorithm choice" section to performance investigations (data shape, operation complexity, memory tradeoff, expected scale). |
| 417 | - Success criterion: fewer ad-hoc optimizations and clearer complexity reasoning in design reviews. |
| 418 | - Confidence: high |
| 419 | |
| 420 | ### Entry 43 |
| 421 | - Source: MIT OCW 6.006 Introduction to Algorithms (`https://ocw.mit.edu/courses/6-006-introduction-to-algorithms-spring-2020/`) |
| 422 | - Date: 2026-02-25 |
| 423 | - Fact: strong algorithm engineering links mathematical modeling, asymptotic analysis, and implementation constraints in one loop. |
| 424 | - Heuristic: validate algorithmic decisions with both proof-level complexity expectations and empirical benchmarks on realistic workloads. |
| 425 | - First adoption task: include one theoretical bound and one measured benchmark for each non-trivial algorithmic change. |
| 426 | - Success criterion: architecture decisions retain both analytical justification and runtime evidence. |
| 427 | - Confidence: high |
| 428 | |
| 429 | ### Entry 44 |
| 430 | - Source: Use The Index, Luke (`https://use-the-index-luke.com/`) |
| 431 | - Date: 2026-02-25 |
| 432 | - Fact: indexing is fundamentally a development-time concern; query shape, predicate form, and pagination strategy dominate SQL performance outcomes. |
| 433 | - Heuristic: design indexes from real query patterns (filter + sort + join), then verify plan behavior instead of relying on default ORM generation. |
| 434 | - First adoption task: capture top query patterns and align index strategy (covering/composite/partial) with execution plans. |
| 435 | - Success criterion: improved p95 query latency with controlled write overhead. |
| 436 | - Confidence: high |
| 437 | |
| 438 | ### Entry 45 |
| 439 | - Source: Google SRE Book TOC (`https://sre.google/sre-book/table-of-contents/`) |
| 440 | - Date: 2026-02-25 |
| 441 | - Fact: reliability at scale is a coherent practice stack (SLOs, alerting, on-call, incident response, postmortems, toil reduction, release engineering). |
| 442 | - Heuristic: treat reliability as a product loop, not as isolated incident handling. |
| 443 | - First adoption task: define minimal reliability operating model for active services (SLO, alert policy, incident template, postmortem cadence). |
| 444 | - Success criterion: clearer operational ownership and faster recovery cycles. |
| 445 | - Confidence: medium |
| 446 | |
| 447 | ### Entry 46 |
| 448 | - Source: OWASP Top 10 project (`https://owasp.org/www-project-top-ten/`) |
| 449 | - Date: 2026-02-25 |
| 450 | - Fact: OWASP Top 10 remains a baseline security awareness standard; current reference line points to 2025 update with structured data-driven process. |
| 451 | - Heuristic: secure coding baselines should be integrated into development workflow (threat review, code review, dependency and input handling checks). |
| 452 | - First adoption task: establish Top-10-mapped secure coding checklist for PR review and test scenarios. |
| 453 | - Success criterion: earlier detection of common web security risk classes before release. |
| 454 | - Confidence: medium |
| 455 | |
| 456 | ### Entry 47 |
| 457 | - Source: Martin Fowler - Technical Debt (`https://martinfowler.com/bliki/TechnicalDebt.html`) |
| 458 | - Date: 2026-02-25 |
| 459 | - Fact: debt is useful as a decision metaphor only when teams explicitly reason about interest vs principal and pay down high-interest hotspots progressively. |
| 460 | - Heuristic: prioritize debt repayment in high-change areas where interest compounds fastest. |
| 461 | - First adoption task: add technical debt annotation to backlog items with "interest signal" (change frequency, cycle delay, defect amplification). |
| 462 | - Success criterion: reduced delivery slowdown in frequently modified modules. |
| 463 | - Confidence: high |
| 464 | |
| 465 | ## Batch 10 (Completed): Platform Reliability and Delivery Operations |
| 466 | |
| 467 | ### Entry 48 |
| 468 | - Source: Azure Well-Architected - Reliability checklist (`https://learn.microsoft.com/power-platform/well-architected/reliability/checklist#checklist`) |
| 469 | - Date: 2026-02-25 |
| 470 | - Fact: reliability can be operationalized as a concrete control loop: flow criticality, failure-mode analysis, target metrics, resiliency tests, BCDR, and monitoring strategy. |
| 471 | - Heuristic: treat reliability as a checklist-backed engineering discipline, not an ad-hoc incident reaction. |
| 472 | - First adoption task: run RE:01-RE:08 checklist against one active service and record gaps as prioritized backlog items. |
| 473 | - Success criterion: visible reduction of unknown failure modes and clearer recovery playbooks. |
| 474 | - Confidence: high |
| 475 | |
| 476 | ### Entry 49 |
| 477 | - Source: Azure Well-Architected - Operational Excellence checklist (`https://learn.microsoft.com/azure/well-architected/operational-excellence/checklist#checklist`) |
| 478 | - Date: 2026-02-25 |
| 479 | - Fact: stable delivery quality is driven by standardized development practices, IaC, automated supply chain, observability, and structured incident management. |
| 480 | - Heuristic: optimize process reliability through explicit standards and automation-first execution. |
| 481 | - First adoption task: introduce OE checklist review for pipeline/tooling decisions (OE:01..OE:08). |
| 482 | - Success criterion: fewer release surprises and faster incident triage under change. |
| 483 | - Confidence: high |
| 484 | |
| 485 | ### Entry 50 |
| 486 | - Source: .NET observability with OpenTelemetry (`https://learn.microsoft.com/dotnet/core/diagnostics/observability-with-otel`) |
| 487 | - Date: 2026-02-25 |
| 488 | - Fact: .NET observability architecture is natively aligned around ILogger + Meter + ActivitySource, with OTel SDK used for collection/export and vendor-neutral telemetry flow. |
| 489 | - Heuristic: instrument once using platform APIs and keep backend choice decoupled through OTel exporters/protocols. |
| 490 | - First adoption task: standardize application instrumentation baseline (logs/metrics/traces) for all new services. |
| 491 | - Success criterion: consistent cross-service diagnostics with minimal vendor lock-in. |
| 492 | - Confidence: high |
| 493 | |
| 494 | ### Entry 51 |
| 495 | - Source: ASP.NET Core health checks (`https://learn.microsoft.com/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-10.0`) |
| 496 | - Date: 2026-02-25 |
| 497 | - Fact: liveness/readiness separation, dependency probes, and orchestrator-integrated endpoints are core to reliable service operation. |
| 498 | - Heuristic: health endpoints should represent operational truth (startup readiness, dependency health, degraded behavior) rather than a single binary ping. |
| 499 | - First adoption task: define `/healthz` + readiness endpoint policy and dependency probe tags for active APIs. |
| 500 | - Success criterion: fewer false-positive restarts and more accurate traffic routing during partial failures. |
| 501 | - Confidence: high |
| 502 | |
| 503 | ### Entry 52 |
| 504 | - Source: GitHub Actions and .NET (`https://learn.microsoft.com/dotnet/devops/github-actions-overview`) + build/test quickstart (`https://learn.microsoft.com/dotnet/devops/dotnet-test-github-action`) |
| 505 | - Date: 2026-02-25 |
| 506 | - Fact: repeatable CI in .NET should center on workflow files with setup-dotnet + restore/build/test stages and explicit secret handling. |
| 507 | - Heuristic: pipeline quality depends on deterministic workflow composition, not just successful ad-hoc command runs. |
| 508 | - First adoption task: validate each .NET repo has a minimal build+test workflow with pinned SDK strategy and status badge. |
| 509 | - Success criterion: reliable CI signal for every PR and lower integration regressions. |
| 510 | - Confidence: high |
| 511 | |
| 512 | ### Entry 53 |
| 513 | - Source: Platform Engineering planning guidance (DORA metrics mention) (`https://learn.microsoft.com/platform-engineering/plan#measure-success-and-proving-value`) |
| 514 | - Date: 2026-02-25 |
| 515 | - Fact: delivery improvement should be measured with outcome metrics such as lead time, deployment frequency, change fail rate, and time to restore service. |
| 516 | - Heuristic: use DORA-like metrics as feedback on engineering system health, not as isolated team scorekeeping. |
| 517 | - First adoption task: define baseline collection for 4 delivery metrics across at least one primary product stream. |
| 518 | - Success criterion: measurable trend visibility for delivery reliability and recovery performance. |
| 519 | - Confidence: medium |
| 520 | |
| 521 | ## Batch 11 (Completed): Compiler Foundations (Dragon Book Layer) |
| 522 | |
| 523 | ### Entry 54 |
| 524 | - Source: Dragon Book overview (`https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools`) |
| 525 | - Date: 2026-02-25 |
| 526 | - Fact: Dragon Book remains the canonical reference for the full compiler chain: lexical analysis, parsing, semantic analysis, intermediate representation, optimization, and code generation. |
| 527 | - Heuristic: treat compiler construction as a pipeline with explicit contracts between stages, not as a monolithic parser task. |
| 528 | - First adoption task: maintain a stage-by-stage architecture template for any language tooling project (tokens -> AST -> typed AST -> IR -> optimized IR -> target code). |
| 529 | - Success criterion: easier debugging and replacement of individual compiler stages without global rewrites. |
| 530 | - Confidence: medium |
| 531 | |
| 532 | ### Entry 55 |
| 533 | - Source: Dragon Book companion site (`https://suif.stanford.edu/dragonbook/`) |
| 534 | - Date: 2026-02-25 |
| 535 | - Fact: companion resources (errata, appendix source code, course links like Stanford CS143/MIT 6.035) are essential for grounding textbook theory in implementable artifacts. |
| 536 | - Heuristic: pair foundational texts with verified companion artifacts to avoid conceptual drift and outdated interpretations. |
| 537 | - First adoption task: create a compiler-study checklist that requires "theory chapter + companion artifact + runnable micro-implementation". |
| 538 | - Success criterion: reduced gap between conceptual understanding and executable implementation. |
| 539 | - Confidence: high |
| 540 | |
| 541 | ### Entry 56 |
| 542 | - Source: LLVM Kaleidoscope tutorial (`https://llvm.org/docs/tutorial/`) |
| 543 | - Date: 2026-02-25 |
| 544 | - Fact: modern compiler workflows are effectively IR-first; early transition to LLVM IR enables optimization/JIT/object generation with reusable backend infrastructure. |
| 545 | - Heuristic: when building DSL/tooling, minimize custom backend work by targeting a mature IR ecosystem as early as possible. |
| 546 | - First adoption task: prototype one minimal expression language that emits LLVM IR before adding advanced syntax. |
| 547 | - Success criterion: working end-to-end prototype with measurable compile/execute loop and extensible backend path. |
| 548 | - Confidence: high |
| 549 | |
| 550 | ### Entry 57 |
| 551 | - Source: Crafting Interpreters contents (`https://craftinginterpreters.com/contents.html`) |
| 552 | - Date: 2026-02-25 |
| 553 | - Fact: language engineering competence requires both interpreter path (tree-walk clarity) and VM path (bytecode/runtime performance and GC realities). |
| 554 | - Heuristic: sequence learning and implementation in two passes: semantic clarity first, runtime efficiency second. |
| 555 | - First adoption task: for new language experiments, implement interpreter baseline before introducing bytecode/VM optimizations. |
| 556 | - Success criterion: faster correctness convergence and fewer premature performance abstractions. |
| 557 | - Confidence: high |
| 558 | |
| 559 | ### Entry 58 |
| 560 | - Source: Dragon Book + LLVM + Crafting Interpreters synthesis |
| 561 | - Date: 2026-02-25 |
| 562 | - Fact: the strongest practical model is a three-layer lens: formal compiler theory (Dragon), industrial IR/toolchain integration (LLVM), and runtime ergonomics (Crafting Interpreters). |
| 563 | - Heuristic: evaluate design decisions by asking three questions: is it formally sound, is it toolchain-compatible, and is it runtime-maintainable? |
| 564 | - First adoption task: introduce this 3-lens review as a mandatory section in language-tooling ADRs. |
| 565 | - Success criterion: fewer dead-end architecture choices in parser/IR/runtime evolution. |
| 566 | - Confidence: medium |
| 567 | |
| 568 | ### Entry 59 |
| 569 | - Source: Dragon Book learning adoption note |
| 570 | - Date: 2026-02-25 |
| 571 | - Fact: Dragon Book is foundational but dense; retention improves when each chapter is converted into one executable artifact and one "error-class map". |
| 572 | - Heuristic: convert each studied compiler topic into "buildable toy + failure taxonomy" rather than passive notes. |
| 573 | - First adoption task: start chapter-to-artifact backlog (lexer DFA, precedence parser, type checker, SSA transform, local optimizer, codegen pass). |
| 574 | - Success criterion: ability to answer design questions with concrete prototypes instead of abstract recollection. |
| 575 | - Confidence: high |
| 576 | |
| 577 | ## Batch 12 (Completed): F# for Production .NET and C# Interop |
| 578 | |
| 579 | ### Entry 60 |
| 580 | - Source: F# style guide (`https://learn.microsoft.com/dotnet/fsharp/style-guide/`) + coding conventions (`https://learn.microsoft.com/dotnet/fsharp/style-guide/conventions`) |
| 581 | - Date: 2026-02-25 |
| 582 | - Fact: large-scale F# remains maintainable when code is organized with explicit namespace/module boundaries, restrained point-free style, and interoperability-aware API shape. |
| 583 | - Heuristic: optimize for readability/tooling/debuggability first; compactness is valuable only when it preserves clarity. |
| 584 | - First adoption task: define team-level F# conventions (namespace-first organization, RequireQualifiedAccess policy, public API naming and argument labels). |
| 585 | - Success criterion: reduced onboarding/debug friction for mixed-skill teams. |
| 586 | - Confidence: high |
| 587 | |
| 588 | ## Batch 13 (Completed): Windows/Linux Environment Foundations |
| 589 | |
| 590 | ### Entry 65 |
| 591 | - Source: Operating System Concepts (Silberschatz/Galvin/Gagne) |
| 592 | - Date: 2026-03-01 |
| 593 | - Fact: core OS guarantees are built around process isolation, virtual memory, scheduling policy, and explicit synchronization contracts; most production failures map to one of these boundaries. |
| 594 | - Heuristic: classify environment incidents by boundary first (process/memory/scheduler/IO/sync) before selecting tools. |
| 595 | - First adoption task: add boundary tag to every OS-related incident note in active projects. |
| 596 | - Success criterion: faster root-cause triage and fewer tool-selection detours. |
| 597 | - Confidence: medium |
| 598 | |
| 599 | ### Entry 66 |
| 600 | - Source: Modern Operating Systems (Tanenbaum/Bos) |
| 601 | - Date: 2026-03-01 |
| 602 | - Fact: different OS families optimize different tradeoffs (throughput, fairness, latency, isolation), so observed behavior can differ even with identical app code. |
| 603 | - Heuristic: treat cross-platform divergence as expected architectural variance, not as random anomaly. |
| 604 | - First adoption task: extend troubleshooting checklists with explicit OS-tradeoff questions (latency vs throughput vs isolation). |
| 605 | - Success criterion: fewer "mystery" discrepancies between Windows and Linux runs. |
| 606 | - Confidence: medium |
| 607 | |
| 608 | ### Entry 67 |
| 609 | - Source: The Linux Programming Interface (Kerrisk) |
| 610 | - Date: 2026-03-01 |
| 611 | - Fact: Linux runtime reliability depends on correct assumptions about file descriptors, signals, process groups, and resource limits. |
| 612 | - Heuristic: verify descriptor/signal/limit state early in Linux incidents before deep app-level debugging. |
| 613 | - First adoption task: add a standard Linux incident probe set (process tree, open files, limits, signal behavior). |
| 614 | - Success criterion: reduced time-to-first-valid-cause in Linux production incidents. |
| 615 | - Confidence: medium |
| 616 | |
| 617 | ### Entry 68 |
| 618 | - Source: Advanced Programming in the UNIX Environment (Stevens/Rago) |
| 619 | - Date: 2026-03-01 |
| 620 | - Fact: robust process supervision and IPC behavior require explicit lifecycle contracts; implicit assumptions around forks/exec/waits often cause unstable orchestration. |
| 621 | - Heuristic: model service startup/shutdown and child-process ownership explicitly in ops-sensitive components. |
| 622 | - First adoption task: audit one worker/service path for lifecycle ownership and shutdown correctness. |
| 623 | - Success criterion: deterministic stop/restart behavior with no orphaned subprocesses. |
| 624 | - Confidence: medium |
| 625 | |
| 626 | ### Entry 69 |
| 627 | - Source: Windows Internals (Russinovich et al.) |
| 628 | - Date: 2026-03-01 |
| 629 | - Fact: Windows behavior in services/security/performance incidents is strongly shaped by token/ACL/session mechanics and kernel object semantics. |
| 630 | - Heuristic: in Windows incidents, verify account/token/ACL context before application logic assumptions. |
| 631 | - First adoption task: add a Windows service-context checklist (identity, ACL, policy, startup account permissions). |
| 632 | - Success criterion: fewer false diagnoses caused by hidden security-context mismatch. |
| 633 | - Confidence: medium |
| 634 | |
| 635 | ### Entry 70 |
| 636 | - Source: UNIX and Linux System Administration Handbook (Nemeth et al.) |
| 637 | - Date: 2026-03-01 |
| 638 | - Fact: environment reliability is maintained by explicit operational contracts (service definitions, logging routes, backup/recovery routines, change discipline), not by ad-hoc admin actions. |
| 639 | - Heuristic: promote "ops as documented contract" for all recurring environment procedures. |
| 640 | - First adoption task: convert one recurring environment fix into a repeatable runbook entry with validation criteria. |
| 641 | - Success criterion: same issue resolved consistently by different operators/agents. |
| 642 | - Confidence: high |
| 643 | |
| 644 | ### Entry 61 |
| 645 | - Source: F# component design guidelines (`https://learn.microsoft.com/dotnet/fsharp/style-guide/component-design-guidelines`) |
| 646 | - Date: 2026-02-25 |
| 647 | - Fact: for cross-language APIs, F# internals can be idiomatic while public boundaries should feel natural to C# (.NET method shape, stable DTO types, avoid exposing curried signatures and opaque unions directly). |
| 648 | - Heuristic: design .NET-facing contracts in C#-friendly form and keep F# expressiveness behind the boundary. |
| 649 | - First adoption task: adopt "interop boundary" rule: public contracts verified from C# usage examples before acceptance. |
| 650 | - Success criterion: predictable consumption from C# with fewer adapter layers. |
| 651 | - Confidence: high |
| 652 | |
| 653 | ### Entry 62 |
| 654 | - Source: Async programming in F# (`https://learn.microsoft.com/dotnet/fsharp/tutorials/async`) + async expressions (`https://learn.microsoft.com/dotnet/fsharp/language-reference/async-expressions`) + task expressions (`https://learn.microsoft.com/dotnet/fsharp/language-reference/task-expressions`) |
| 655 | - Date: 2026-02-25 |
| 656 | - Fact: F# async workflows are compositional and concise; task expressions are preferred at heavy .NET Task interop boundaries and can directly await Task/ValueTask/Async. |
| 657 | - Heuristic: default to `async` for internal orchestration, use `task` at API edges where C#/.NET task semantics are the primary contract. |
| 658 | - First adoption task: codify async policy in architecture docs (internal async model vs external task model, conversion points via AwaitTask/StartAsTask). |
| 659 | - Success criterion: fewer async interop bugs and clearer cancellation/await behavior. |
| 660 | - Confidence: high |
| 661 | |
| 662 | ### Entry 63 |
| 663 | - Source: Type providers overview (`https://learn.microsoft.com/dotnet/fsharp/tutorials/type-providers/`) + FSharp.Data docs via Context7 (`/fsprojects/fsharp.data`) |
| 664 | - Date: 2026-02-25 |
| 665 | - Fact: type providers enable schema-driven, strongly typed integration for external structured data; this is highly aligned with portal/IM ingestion layers. |
| 666 | - Heuristic: use type providers for exploratory or adapter layers where schema fidelity is critical; isolate provider usage behind stable domain transformations. |
| 667 | - First adoption task: pilot one ingestion adapter (e.g., CSV/XML/JSON) using FSharp.Data type provider mapped to canonical domain records. |
| 668 | - Success criterion: lower runtime parsing failures and faster evolution with schema changes. |
| 669 | - Confidence: medium |
| 670 | |
| 671 | ### Entry 64 |
| 672 | - Source: .NET language strategy - F# (`https://learn.microsoft.com/dotnet/fundamentals/languages#f`) |
| 673 | - Date: 2026-02-25 |
| 674 | - Fact: Microsoft positions F# as robust, performant, and interoperable with C# in mixed-language solutions, with active community/compiler evolution. |
| 675 | - Heuristic: for complex domain transformation and validation pipelines, F# + C# hybrid architecture is a strategic fit, not an edge-case compromise. |
| 676 | - First adoption task: define language ownership map per service layer (F# for domain transformation/validation passes, C# for mainstream host/API/UI integration). |
| 677 | - Success criterion: better leverage of each language without architectural fragmentation. |
| 678 | - Confidence: high |
| 679 | |
| 680 | ## Batch 14 (Completed): IT Phase C - Cloud, Economics, and Scale Diagnostics |
| 681 | |
| 682 | ### Entry 71 |
| 683 | - Source: DORA 2024 report (`https://dora.dev/research/2024/dora-report/`) |
| 684 | - Date: 2026-03-01 |
| 685 | - Fact: delivery performance and reliability should be evaluated together (throughput + stability), with evolving interpretation of restoration/rework dimensions. |
| 686 | - Heuristic: avoid single-metric optimization; make release decisions on a balanced reliability-speed profile. |
| 687 | - First adoption task: add DORA-style dashboard slice to active delivery stream reviews. |
| 688 | - Success criterion: fewer conflicting decisions between speed and stability goals. |
| 689 | - Confidence: medium |
| 690 | |
| 691 | ### Entry 72 |
| 692 | - Source: FinOps Framework overview + unit economics (`https://learn.microsoft.com/en-us/cloud-computing/finops/framework/finops-framework`, `https://www.finops.org/framework/capabilities/unit-economics/`) |
| 693 | - Date: 2026-03-01 |
| 694 | - Fact: cloud governance matures when spend is mapped to business units and operated as continuous collaboration loop. |
| 695 | - Heuristic: architecture economics should be tracked per business capability, not only as aggregate infrastructure cost. |
| 696 | - First adoption task: define one unit-economics metric for a critical capability and publish ownership. |
| 697 | - Success criterion: cost changes become interpretable in business terms. |
| 698 | - Confidence: high |
| 699 | |
| 700 | ### Entry 73 |
| 701 | - Source: Google SRE workbook - eliminating toil + alerting on SLOs (`https://sre.google/workbook/eliminating-toil/`, `https://sre.google/workbook/alerting-on-slos/`) |
| 702 | - Date: 2026-03-01 |
| 703 | - Fact: sustainable reliability requires toil budgeting and burn-rate-based SLO alerting rather than ad-hoc threshold paging. |
| 704 | - Heuristic: protect engineering capacity by converting repetitive operational load into automation backlog. |
| 705 | - First adoption task: classify top repetitive ops tickets and create first automation candidates. |
| 706 | - Success criterion: measurable reduction in repetitive manual incidents. |
| 707 | - Confidence: high |
| 708 | |
| 709 | ### Entry 74 |
| 710 | - Source: AWS Well-Architected Cost Optimization principles (`https://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/cost-dp.html`) |
| 711 | - Date: 2026-03-01 |
| 712 | - Fact: cost optimization is design-time discipline (consumption model, attribution, efficiency measurement), not post-hoc trimming. |
| 713 | - Heuristic: require cost impact notes in architecture options before implementation. |
| 714 | - First adoption task: include cost design principles section in ADR template. |
| 715 | - Success criterion: fewer expensive architecture reversals. |
| 716 | - Confidence: high |
| 717 | |
| 718 | ### Entry 75 |
| 719 | - Source: Kubernetes SLI metrics + disruption budgets (`https://kubernetes.io/docs/reference/instrumentation/slis/`, `https://v1-32.docs.kubernetes.io/docs/tasks/run-application/configure-pdb`) |
| 720 | - Date: 2026-03-01 |
| 721 | - Fact: platform reliability is enforceable through measurable control points (component SLIs, disruption budgets). |
| 722 | - Heuristic: separate platform-level objectives from application-level objectives to avoid blurred accountability. |
| 723 | - First adoption task: document one workload disruption budget with expected availability impact. |
| 724 | - Success criterion: fewer avoidable outages during maintenance/rollouts. |
| 725 | - Confidence: medium |
| 726 | |
| 727 | ### Entry 76 |
| 728 | - Source: OpenTelemetry metrics SDK spec (`https://opentelemetry.io/docs/specs/otel/metrics/sdk`) |
| 729 | - Date: 2026-03-01 |
| 730 | - Fact: observability quality and cost are strongly influenced by cardinality controls and view-level aggregation choices. |
| 731 | - Heuristic: design telemetry with signal budget constraints from day one. |
| 732 | - First adoption task: define forbidden high-cardinality metric attributes for default instrumentation. |
| 733 | - Success criterion: stable telemetry cost with preserved incident diagnosability. |
| 734 | - Confidence: medium |
| 735 | |
| 736 | |