Projects: classes as entities, and the sidebar fits short windows

A project is a class with facts (description, status, kind, party,
dates, links, notes) in one project.set event behind the format
feature projects. Four tools (books.add_project, update_project,
projects, project); documents and decisions link to projects; B-37:
on-spec costs are expensed as incurred, repayment is revenue, and the
unrecovered cost is never below zero (Kani). Viewer: a Projects list
and a project page with its figures, by month and by account. The
sidebar measures its footer instead of reserving a fixed 172 px.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T3gXMVt7XJPi6ens1or9Dj

docs/capability-parity.md

@@ -35,6 +35,11 @@ Statuses: `covered` (built and tested), `partial` (built, known gaps listed),
 - Row 10 (`books.digest`) has no sheet equivalent — the sheet can't tell you
   what changed. This is parity *plus*: the new system is more reviewable
   than the old one, which is the point of the exercise.
+- Projects (rules.md B-37) have no sheet equivalent either: a class with
+  its facts, created and changed by the agent (`books.add_project`,
+  `books.update_project`), read by the viewer's Projects pages and by
+  `books.projects` / `books.project` (D-28: the agent writes, the viewer
+  reads).
 - Row 12 is deliberately excluded. Email filing is a mail problem, not a
   books problem; it stays where it is.