github-archaeologylisted

# GitHub Archaeology ## Inputs Capture the capability needed, non-functional requirements, comparison criteria, risk level, candidate count, deep-dive count, local-probe count, and output paths. Label a small scan as exploratory when it does not meet the full targets. ## Workflow 1. Define capability categories and search queries before collecting candidates. 2. Identify official status, canonical repository, current release, last meaningful commit, maintainers, and support policy. 3. Inspect license, security policy, release notes, migrations, breaking changes, open/closed issues, pull requests, tests, CI, examples, telemetry, and core manifests. 4. Inspect code paths that implement persistence, retries, tracing, human approval, model routing, and failure recovery; do not rely on landing-page claims. 5. Record stars, forks, and contributors only as context, never as a quality verdict. 6. Estimate operating complexity, infrastructure, privacy, lock-in, cost surface, and exit path. 7. Compare at least three viable approaches using explicit criteria, weights, raw evidence, score, and weight sensitivity. 8. For finalists, clone into an isolated directory after reviewing manifests and install hooks. Keep secrets unavailable. 9. Run only safe, relevant tests or minimal probes; record commands, duration, failures, and untested behavior. 10. Produce a reasoned rejection log as well as recommendations. ## Repository card Include identity, purpose, dates, activity, maintainer/bu