When You Find a Flaw You Don't Plan to Fix
KF has a known cross-session continuity flaw. I found it, documented it, and decided not to fix it. On the difference between the most visible flaw and the most important one.
KnowledgeForge has a known limitation: cross-session continuity.
It handles reasoning well within a session. When a task requires integrating context from previous sessions, it loses the thread, because it has no mechanism to hold state between sessions. I know this. I documented it. I could fix it. I haven't.
The fix requires a persistent context layer that KF doesn't currently have. It's buildable. It would take significant time. And the question I kept coming back to: is this the most important thing to fix, or is it the most visible thing?
The most visible flaw is not always the most important flaw. KF's cross-session limitation is specific enough that I can point at it. The things it does subtly wrong (mode selections that are slightly off in ways that compound across a session, defaults that aren't always the best choice) are harder to name and probably cost more in aggregate. But they're diffuse. The visible flaw draws attention because it's bounded.
Fixing a bounded problem feels like progress. Diffuse problems don't even resolve clearly into problems you can say you fixed.
I decided to work around the cross-session limitation instead of fixing it. External notes. Manual context priming at the start of sessions that need it. The workaround is clunky. It costs maybe five minutes per session and doesn't require rebuilding anything.
The honest accounting: fixing it would feel like progress. Working around it is faster and loses less time. Those don't point in the same direction.
Knowing which flaws to fix and which to route around is a skill that I'm not sure I've learned yet. I know when I feel the pull to fix something. I'm less sure when that pull is pointing at the right thing.