Repo archaeology uses commit history as evidence for how a project was actually built, where it got stuck, and what the next intervention should be. It is useful because code history is harder to fake than a positioning paragraph.
Kyanite's repo-intelligence work exists because AI-assisted teams generate a lot of motion. The question is which motion taught the system something, which motion created debt, and which motion can become public proof.
Commit history is a diagnostic surface
A repo carries behavioral evidence: repeated fixes, reverted directions, test gaps, naming churn, and stale public metadata. A good diagnostic does not shame the team for that. It turns the pattern into a map.
signals:
- repeated failure around release automation
- docs updated after code, not before
- tests added only after regressions
- public metadata lagging behind repo renameThe tradeoff is that history is noisy. Repo archaeology needs filters, not mysticism.
Why this matters for users
Users do not only need the current feature set. They need confidence that the tool can keep improving. Public history, issue handling, release notes, and verified fixes show maintenance behavior.
That is why Dev Learning Archaeologist and devarch-framework belong on the Kyanite proof wall. They turn invisible engineering behavior into something a person can inspect.
FAQ
Is repo archaeology only for learning diagnostics?
No. It is also useful for product audits, acquisition diligence, maintainer handoffs, launch readiness, and deciding which proof assets should be public.