Explanation

Understanding-oriented discussion of 2P-Kt's design and the rationale behind it: why things are the way they are, not just how to use them.

Suggested reading order

Roughly: why the project exists, then the core data model, then increasingly specific engine internals, ending with a few build-tooling rationale pages that are useful mostly to contributors:

1. Project history — from tuProlog's Java origins to the 2P-Kt rewrite.
2. Philosophy — the design philosophy behind 2P-Kt's modular architecture.
3. Term model — why terms are immutable and what that buys you.
4. Variables and scoping — why Var equality/scoping works the way it does.
5. Clause databases and RETE — how theories index clauses for fast matching.
6. Solver design — the rationale behind the Solver/Solution API's shape.
7. The solve-classic state machine — how the classic SLD-resolution engine actually runs.
8. Parser architecture — how Prolog source text becomes terms and theories.
9. I/O library design — why :io-lib's Url/channel split looks the way it does.
10. Kotlin Multiplatform — why 2P-Kt targets multiple platforms from one codebase.
11. Gradle multi-project build — why ~30 modules instead of one.
12. Kotlin DSL background — why the build itself is written in Kotlin DSL.