Add markproof init, and the files a public repo is expected to have

[Tippel-AI]

Final step of the audit remediation.

markproof init

The CLI's module docstring promised this command since M4:

``verify-report``, ``keygen`` and ``init`` arrive with the signed report in M4.

Two of the three shipped. A promised-but-absent command tells a reader the
documentation is not checked against the code — the wrong first impression for a
tool whose subject is verification, and part of why the adoption axis graded
weak.

The scaffold is deliberately small: one chat probe, with media, UI and text
marking commented out and each carrying the reason it is optional. A config
full of settings nobody chose is how people end up running checks they cannot
interpret. It refuses to overwrite an existing file, and it points a newcomer at
examples/demo-bot, because someone evaluating this tool may not have an endpoint
of their own yet.

The load-bearing test is that the output actually loads through load_config and
names a rulepack that ships. A scaffold that fails validation would be worse than
no command at all.

Community files

Not copied from a template — two of them are shaped by what this project is:

"A verdict looks wrong" asks which direction the verdict went and names
PASS where I expected FAIL first, as the outcome nothing downstream will catch.
It asks for report.json specifically: since #25 that file carries the rulepack
digest and the probe URLs, so a run can be reconstructed from it.

"A rule reads the law wrong" points at docs/RULES_SOURCES.md first and says
plainly that legal disagreement is welcome. The rulepacks are CC-BY and cite their
paragraphs precisely so that argument can be had in the open — the project does
not claim to be right about Article 50, it claims to be explicit about what it
checks.

The contact links route security reports to a private advisory, and route
"is my system in scope?" to the Commission, because that question is for a
lawyer and not for this tool.

The code of conduct says the thing that matters here — argue with the work,
and distinguish "I ran it and it failed" from "I think it would fail" — and is
honest that this is maintained by one person alongside other work, so some good
contributions will not be merged.

Plus CITATION.cff, since the rulepacks are citable material in their own right.

444 tests, ruff + mypy strict clean.

Where the audit stands after this

Axis	Was	Addressed by
first-contact	weak	#23
correctness	adequate	#24, #25
tests	weak	#24, #26
honesty	adequate	#20, #27
release	adequate	#23, #28
adoption	weak	#26, #28, this
architecture	adequate	#24, #28

Still open: #18 (C2PA-in-HTML rule), #19 (marking vs detectability in the report),
#1 (PyPI upload, which is yours to do).

🤖 Generated with Claude Code