Drop the ChainDepState / BlockProtocol / Praos references and
replace with neutral F / G / Bar shapes. The viewer is meant to be
project-agnostic; baking downstream package vocabulary into the UI
text was a leak.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
<p>Use site that classgraph couldn't match against any known fam-instance. Two common reasons:</p>
<ol class="placeholder-reasons">
<li><strong>External family</strong> — the family's equations live in a package you haven't extracted. Re-run the plugin against the defining package to surface them here.</li>
- <li><strong>Nested or abstract args</strong> — classgraph doesn't fully simulate GHC's type-family rewrite chain. For example, <code>ChainDepState (BlockProtocol blk)</code> won't match a concrete instance like <code>ChainDepState (Praos c)</code> unless we can first reduce <code>BlockProtocol blk</code> to a <code>Praos _</code> shape; if <code>blk</code> stays abstract or the inner reduction fails, the outer family looks unresolvable even though the equations are in your dumps.</li>
+ <li><strong>Nested or abstract args</strong> — classgraph doesn't fully simulate GHC's type-family rewrite chain. For example, <code>F (G a)</code> won't match a concrete instance like <code>F (Bar c)</code> unless we can first reduce <code>G a</code> to a <code>Bar _</code> shape; if <code>a</code> stays abstract or the inner reduction fails, the outer family looks unresolvable even though the equations are in your dumps.</li>
</ol>
<p class="placeholder-hint">Open the family node (the diamond above this row) to see all the fam-instances we <em>do</em> have for it — one of them may be the satisfier in the actual program.</p>
</dd>