Evolution is a reading workflow

Evidence legend: Durable marks a reusable investigation method; Version-specific marks a pinned implementation or release entry; Experimental marks a flag, deprecation, proposal, or transitional path.

Compose internals move. Ask each source what it can prove: tests/generated artifacts bound behavior; history explains transitions; release notes establish shipping; design docs preserve historical intent and terminology but may lag; roadmaps show intent only.

Use the evidence ladder

Use this precedence: pinned implementation → tests/generated evidence → history → release notes → design docs → roadmap.

Start with pinned implementation. ComposeRuntimeFlags.kt exposes experimental isLinkBufferComposerEnabled, default false; Composition chooses a composer from it. This proves a source-snapshot default, not a released-artifact promise.

Next inspect tests/generated evidence. CompositionObserverTests.kt gives named assertions; a compiler golden shows fixed-input output. Neither proves universal behavior.

Then inspect history. Gitiles/Gerrit can show whether a default, test, or name changed and why; history explains a transition, not present behavior. Read release notes next: the page accessed 2026-07-12 lists 1.12.0-beta02 with a nested-movable-content LinkComposer fix and beta01 with an invalidation fix. These establish shipped fixes, not every private detail in the pinned head (release notes).

Next consult this historical runtime design note. Design docs provide historical intent/terminology, may lag, and are subordinate to current pinned code, tests/generated evidence, and history. The pinned Composer deprecates setDiagnosticStackTraceEnabled in favor of setDiagnosticStackTraceMode (Composer.kt#L957-L978); the roadmap is intent only.

Keep these labels beside your notes:

Keep an update record

For a changed mechanism, record six lines in order:

1. Observed now: pinned file, symbol, revision, and gate/deprecation.
2. Verified: named test assertion or generated output.
3. Changed from: history/change link and old behavior, if verified.
4. Shipped in: release-note version, if present.
5. Design context: historical intent/terminology; note lag and subordinate status.
6. Still intended: roadmap wording, intent only.

This separates release fixes and design proposals from current implementation. Revisit a line when its flag default, test/generated output, release entry, design note, or roadmap status changes.

Reproduce the workflow

Compare the generated compiler golden linked above. At the pinned AndroidX checkout:

PIN=cc1caf65677fc10a8ce8116eba46e716f4cef222
git show "$PIN:compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/ComposeRuntimeFlags.kt" \
  | grep -n -A8 -B4 'isLinkBufferComposerEnabled'
git show "$PIN:compose/runtime/runtime/src/nonEmulatorCommonTest/kotlin/androidx/compose/runtime/CompositionObserverTests.kt" \
  | grep -n -A6 -B2 'Observer'
git log --oneline -S'isLinkBufferComposerEnabled' -- \
  compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/ComposeRuntimeFlags.kt
git log --oneline -G'@Deprecated|@Experimental' -- \
  compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/{Composer.kt,MonotonicFrameClock.kt}

Then open the Gerrit history query, release notes, design note, and roadmap, in that order.

Controls: compare code with tests/generated evidence, then history, release status, design terminology, and roadmap intent; never use design or roadmap prose as a runtime control. Expected: assertions/output, the history trail, shipped versions, design vocabulary, and future-facing roadmap statements are visible. Limits: rate limits, moving searches, and a pinned snapshot can leave applicability unresolved. This procedure was not executed in this content edit.

Misconceptions and check

• “Latest androidx-main is the latest Maven artifact.” A branch snapshot and release page answer different version questions.
• “A deprecation means removal already happened.” It is a migration signal; check current API, tests, and release notes.
• “A design doc or roadmap item proves the feature exists.” Design docs explain historical intent; roadmaps prove intent only.
• “One history commit explains the whole design.” Follow current implementation and tests after reading rationale.

When a new release changes a mental model, record which evidence rung changed. If only the design doc or roadmap changed, keep teaching current behavior and label the intent.

Evidence ledger

Freshness

Refresh on each runtime/compiler release, flag/deprecation change, relevant Gerrit patch, benchmark change, design-doc update, or roadmap update. Re-run the evidence ladder before changing course-wide conclusions.