ck-learnlisted

# K→K — expanding knowledge, and the K→C return path K→K is not general research. It is research aimed at **changing the decidability of a specific concept**. Always name the target node before you start. Read `${CLAUDE_PLUGIN_ROOT}/references/GRAMMAR.md` first. ## Procedure ### 1. State the question the branch is blocked on Write it explicitly, as one sentence: *"What would have to be true for C6 to be buildable?"* or *"Is the constraint in K2 a law, or an artefact of how it's usually done?"* The second form is disproportionately productive. Constraints in K are often contingent — true of the usual implementation, not of the object. Finding that out is what unlocked the worked example. ### 2. Research Use `WebSearch` and `WebFetch`. Prefer primary sources: standards, specifications, patents, papers, manufacturer data. Patents are especially good here — they document attributes that were *tried*, which is exactly what K→C needs. Keep each K entry to one proposition. Compound entries can't be referenced cleanly by a concept node. ### 2b. Hunt specifically for the K that softens definitions Not all knowledge helps a design. The C-K literature is unusually specific about which kinds of K make expansive partitions *formulable at all*, and this instruction is the most under-used thing in the method. Go looking for: - **Paradoxes** — where the object's own field contradicts itself - **Polysemy** — the several incompatible things the object's *name* denotes - **Strange c