FIELDNOTE INDEX

Engineering notes

These notes use dependency injection as an architecture signal. They focus on questions that survive framework changes: what owns an object, when it stops existing, which module may construct it, and how a team can prove the graph still works.

NOTE / 2026.08

Add the dependency graph to a Kotlin K2 migration checklist

Compiler and Compose migrations can affect generated wiring, metadata, plugins, and target compatibility.

NOTE / 2026.08

Build a dependency-graph inventory before changing the container

A small inventory makes hidden constructors, qualifiers, scopes, and platform bindings easier to review.

NOTE / 2026.08

Find technical debt at dependency-injection boundaries

Container definitions expose ownership confusion, oversized modules, unstable qualifiers, and concealed side effects.

NOTE / 2026.08

Keep Kotlin Multiplatform bindings at the platform boundary

Shared code should describe the capability it needs while each target supplies the platform implementation.

NOTE / 2026.08

Match Compose injection scopes to real UI ownership

Recomposition, navigation, and process lifetime are different events; a dependency scope must say which one it follows.

NOTE / 2026.08

Review a Koin upgrade as a graph change, not a version bump

A controlled upgrade checks definitions, scopes, package changes, startup paths, and rollback evidence.

NOTE / 2026.08

Turn a framework roadmap into an application decision record

A roadmap is a direction signal; an application still needs evidence, constraints, and a local adoption decision.

NOTE / 2026.08

Use compile-time DI checks without losing runtime tests

Compiler validation catches structural errors; runtime tests still cover parameters, configuration, and lifecycle behavior.