I don't have the new version up on Github yet, but App::Prove::History is coming along nicely. I've committed a few changes to Test::Harness to make this work (primarily to pass a TAP::Parser instance along), so even if I post to Github, you wouldn't be able to test it without checking the latest Test::Harness out of Subversion.
I hope to have it on Github this weekend, but it won't go to the CPAN until there is an official Test::Harness release supporting the features I need (something I've not been pressing for because stability of Test::Harness is far more important than my work, but maybe a developer release is in order).
One problem I've already been hit with repeatedly is the evolving underlying schema. I have several changes in mind, but I won't allow this to hold up an alpha release. I think what I need to do is use DBIx::Migration to handle the changes, make it easier to specify an alternate database (PostgresQL or MySQL instead of SQLIte, for example), and maybe write some "cookbook" examples of how to upgrade a database without losing data. Still, making this code properly database independent might mean switching to an ORM and I'm reluctant to add that overhead to test runs.
I also need to write some cookbook examples of SQL to read the database from as I haven't provided a clear API for it. I've now documented the schema, but I may need to provide views and deprecation schedules to handle the schema evolution. It's one thing to provide code for the massses. It's another thing to provide data.