4.2 KiB
4.2 KiB
Reviewing Geolog
This guide is for humans reviewing the codebase, especially when you want to answer:
- where a behavior lives,
- which commands to run first,
- and which modules are most likely to matter for a given bug or change.
Quick Start
If you have just installed:
just review
just review-gui
Without just:
cargo check
cargo test
cargo check --features gui --bin geolog-gui
cargo test --features gui
Best Reading Order
For most reviews, this order gives the fastest mental model:
README.md- User-facing behavior and examples.
docs/ARCHITECTURE.md- High-level subsystem map.
src/lib.rs- Top-level module layout.
- Syntax pipeline
src/ast.rssrc/lexer.rssrc/parser.rssrc/pretty.rs
- Semantic core
src/core.rssrc/id.rssrc/universe.rs
- Elaboration
src/elaborate/mod.rssrc/elaborate/theory.rssrc/elaborate/instance.rs
- Runtime and persistence
src/repl.rssrc/store/mod.rssrc/store/theory.rssrc/store/instance.rs
- Query and chase
src/query/mod.rssrc/query/chase.rssrc/query/compile.rssrc/query/backend.rs
- Optional layers
src/solver/src/gui/
How To Map A Change
Use this shortcut table:
- Parse error or syntax ambiguity
- Start in
src/lexer.rsandsrc/parser.rs.
- Start in
- Pretty-print or round-trip bug
- Start in
src/pretty.rs, thentests/unit_pretty.rsandtests/unit_parsing.rs.
- Start in
- Wrong theory or instance semantics
- Start in
src/elaborate/andsrc/core.rs.
- Start in
- Persistence or workspace bug
- Start in
src/repl.rsandsrc/store/.
- Start in
- Chase/query behavior bug
- Start in
src/query/chase.rs,src/query/compile.rs, and related tests.
- Start in
- GUI-only behavior bug
- Start in
src/gui/state.rs, thensrc/gui/panels/orsrc/gui/visualizations/.
- Start in
Important Invariants
parsershould stay syntax-focused.- Semantic decisions generally belong in elaboration, not parsing.
coreshould remain GUI-free.- GUI code should consume existing semantics, not define them.
- GUI must remain feature-gated.
- GUI code lives behind the
guifeature.
- GUI code lives behind the
- Persistence changes need extra care.
src/store/and related runtime flows should preserve expected workspace behavior.
- Chase/query changes need explicit tests.
- These regressions are often subtle and easy to miss in manual review.
Best Review Commands
Start narrow, then go broad.
Core checks
cargo check
cargo test
GUI checks
cargo check --features gui --bin geolog-gui
cargo test --features gui
Focused checks
cargo test unit_parsing
cargo test unit_elaborate
cargo test unit_chase
cargo test unit_workspace
cargo test gui_
Test File Guide
tests/unit_parsing.rs- Parser and syntax behavior.
tests/unit_pretty.rs- Pretty-printing and round-trip expectations.
tests/unit_elaborate.rs- Theory/instance elaboration semantics.
tests/unit_chase.rs- Chase behavior.
tests/unit_workspace.rs- Persistence/workspace behavior.
tests/examples_integration.rs- End-to-end examples.
tests/proptest_*.rs- Property-based coverage.
What Usually Deserves Extra Scrutiny
- Changes that cross parser → elaboration boundaries.
- Changes in
src/core.rsbecause they affect many layers. - Anything in
src/query/chase.rs,src/query/backend.rs, orsrc/store/. - GUI changes that mutate runtime state rather than only presenting it.
- Feature-gated code that may compile less often than the default build.
Useful Missing Context To Watch For
If a patch is hard to review, it often needs one of these:
- a smaller regression test,
- a more focused example in
examples/geolog/, - a note in
docs/ARCHITECTURE.md, - or a short comment explaining a non-obvious invariant.
Reviewer Checklist
- Does the change live in the right layer?
- Are semantics changed intentionally, or just presentation?
- Is there a narrow test for the bug or behavior?
- If GUI code changed, is the same state transition safe from the REPL path too?
- If store/query/chase code changed, do existing tests still cover the affected behavior?
- Is any documentation now stale?