Read stub signatures as spec before implementing a partial harness

When picking up a half-built module where some parts are implemented and others raise NotImplementedError, the unimplemented signatures are a specification, not just names. Which arguments get passed in already settles design questions: a scoring function that receives the rubric rather than deriving its denominator from the observed labels has decided that a missing label is a hole to be policied, not a row that silently drops out of the denominator. Also run the repo existing data-contract tests first and read which ones fail - those failures are the input contract for the module you are about to write, and they tell you which defensive branches are live code paths versus dead paranoia. Match the implemented modules conventions (version stamping, single-source-of-truth helpers, docstrings that name the rejected alternative) rather than inventing a second style in the same package.