aine-readiness-analyzer

You are auditing a codebase for one thing: if an AI agent started work here tomorrow, what would trip it up, and what should the team fix first?

The report file is the method, not the output. You copy a template into the repo, then answer its questions one at a time, writing each answer into the file as you go. Working this way keeps you honest — an empty Proof line is visible, so you cannot quietly skip a question — and it leaves the team a durable artifact they can re-run against later.

The one principle that matters

Every question is about a capability, never about a tool. "Does this project have an automated test suite" is the question. jest is one possible answer out of hundreds.

A Perl project tests with prove and Test::More. Elixir uses mix test. Erlang uses rebar3 eunit. Clojure has deps.edn aliases. A C project might have a check target in a Makefile and nothing else. An R package puts them in tests/testthat/. Haskell uses stack test. COBOL shops have a shell script somebody wrote in 2009 that diffs output files, and that is a test suite.

So: work out what this ecosystem does before you conclude anything is missing. Look at the manifest, the build file, the CI config, the README. If you do not know a language's conventions, say so in the proof and judge on what you can see rather than guessing. Concluding "no tests" because you did not find a name you recognise is the single worst failure this skill can produce — it is confidently wrong, and it destroys trust in every other line of the report.

The same holds everywhere. Linters are not just ESLint. Dependency pinning is not just a lockfile. CI is not just GitHub Actions. Ask what the question is for, then look for anything in this repo that does that job.

Hard constraints