bill
ab1f29269e
Mark engine as done in overview and build order. Update next-steps to focus on test gap analysis. Add engine file map, data flow, and dev setup quirks (Zeitwerk conflict, engine routes conflict) to architecture. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
32 lines
1.5 KiB
Markdown
32 lines
1.5 KiB
Markdown
# Whetrails — Project Handoff
|
|
|
|
## What this is
|
|
|
|
A Ruby gem that makes ActiveRecord callback and validation chains visible to developers.
|
|
|
|
When a Rails developer calls `.save` on a model, Rails fires a chain of callbacks and validations in a specific order. These are registered in scattered places (the model file, concerns, gems) and Rails never surfaces the full picture in one place. Whetrails extracts and displays that chain: what fires, in what order, where it's defined, and under what conditions.
|
|
|
|
This is the first half of a two-part tool. The second half (not yet built) uses the extracted chain as input to a test coverage gap analyzer — showing which callbacks and validators are never exercised by the test suite.
|
|
|
|
## Current state (as of 2026-06-08)
|
|
|
|
Three layers are complete:
|
|
|
|
1. **Core inspector** — extracts the full chain from any ActiveRecord model class at runtime
|
|
2. **CLI** — `whetrails inspect <ModelName>` boots the host Rails app and renders the chain to the terminal
|
|
3. **Rails engine** — browser UI mounted at `/whetrails`, sidebar model list, lifecycle timeline with vscode source links
|
|
|
|
## Build order
|
|
|
|
```
|
|
[DONE] 1. Gem core lib/whetrails/inspector.rb
|
|
[DONE] 2. CLI exe/whetrails + lib/whetrails/cli.rb
|
|
[DONE] 3. Rails engine browser UI mounted at /whetrails
|
|
[NEXT] 4. Test gap layer uses chain data to find uncovered callbacks/validators
|
|
```
|
|
|
|
## Repository
|
|
|
|
- Gitea: http://localhost:3000/bill/whetrails
|
|
- Branch: main
|