状態: Accepted
20-architecture.md 3節は early cutoff を必須の最適化と 定めている。「コメント編集がアクショングラフ再生成に波及しないのはこの機構による」 とも述べている。
ファイル単位のクエリではこれが原理的に効かない。値はスパンを含み、スパンは ファイル内のバイト位置である。コメントを1行足すと全てのスパンがずれるため、 「中身が変わったのに評価結果は同じ」という状況が起きない （99-open-questions.md Q9）。
効かせるにはターゲット単位の派生（interface と compile_env）をクエリにし、
その指紋をスパンを含まない要約から導く必要がある。しかし同じ値は来歴を持ち、
来歴はスパンを含む。cutoff が起きるとメモに残った値の来歴は直前の編集を
反映しない。
派生クエリの指紋はスパンを含まない要約から導く。要約が同じなら、値の来歴が 古いままでも再計算しない。
来歴のスパンを表示する経路（dowel why）はメモを経由せず、その場で併合を
やり直す。
診断は値に含め、指紋にも含める。診断はスパンを持つため、位置が動けば cutoff は 起きない。
下流が来歴から読むのは宣言位置のファイル（FileId）だけである。パスは
「パッケージルートからの相対」で表され、基点は値ではなく宣言位置が持つ
（10-manifest.md 3節）。FileId は正規化したパスの
ハッシュであり編集では変わらない（ADR-0009）ため、
要約に含めれば下流の結果は正しいままである。
来歴の共有をやめて dowel why を計算し直すことには、
20-architecture.md 4節の
「来歴はクエリグラフの射影である」という位置づけとの整合がある。射影であるなら、
保持ではなく再構成で得られる。
診断を指紋に含めるのは、位置の古い診断を出さないためである。誤りのある構成では 再計算を選ぶ。cutoff の利得を失うのは誤りが残っている間だけであり、 その間は利用者が編集を繰り返している最中である。
要約にスパンを含める。 cutoff が起きないため、この決定の目的を満たさない。
来歴を値から外す。 Value = { type, data, provenance }
（20-architecture.md 4節）を崩す。来歴を副次情報として
別に持つと、伝播の途中で対応が失われる箇所が生じる。
cutoff の後で来歴だけを差し替える。 差し替えには値の木の全走査が要る。 20-architecture.md 5.1 の「ノードの実体は必要になるまで 読まない」と衝突する。
Interfaces（併合結果を下流へ配る器）は不要になった。依存のインタフェースは
クエリが自身で辿るため、plan と why へ持ち回る必要がない。
検査は a_comment_only_edit_does_not_reach_the_merge と
changing_a_declared_value_reaches_the_merge（incremental.rs）が対で行う。
前者だけでは「そもそも併合を問い合わせていない」状態でも通る。
dowel why は毎回併合をやり直す。対象は1ターゲットとその依存であり、
グラフ全体ではない。