bill
6dd78f2487
Overview, architecture notes, and next steps for anyone picking this up — including Rails API gotchas discovered during implementation. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
33 lines
1.4 KiB
Markdown
33 lines
1.4 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)
|
|
|
|
Two 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
|
|
|
|
The next layer (Rails engine / browser UI) has not been started.
|
|
|
|
## Build order
|
|
|
|
```
|
|
[DONE] 1. Gem core lib/whetrails/inspector.rb
|
|
[DONE] 2. CLI exe/whetrails + lib/whetrails/cli.rb
|
|
[NEXT] 3. Rails engine browser UI mounted at /whetrails
|
|
4. Test gap layer uses chain data to find uncovered callbacks/validators
|
|
```
|
|
|
|
## Repository
|
|
|
|
- Gitea: http://localhost:3000/bill/whetrails
|
|
- Branch: main
|