feat: invoices and bills take a project, line by line (B-37 item 8)

A client project's invoiced revenue and a contractor's billed cost could
never count toward the project: books.create_invoice and books.create_bill
posted at once with untagged lines, and only a draft's line takes a class.
Job costing (B-37 item 3) collects a job's billings and the supplier
invoices for its direct costs on its cost sheet, so each document line
now takes an optional project.

The owner decided it on 2026-10-22 (plan D-43, rules.md B-37 item 8):
each line takes one project or none; a document spanning N projects is N
lines, each with its own amount; no percentage split, so every figure is
exact; a cost truly shared among projects names none on the document
and reaches projects only as entries of their own under the company's
monthly allocation convention, when books.conventions has one (otherwise
it stays untagged and the agent asks the human). The reasoning, stated
in B-37: job costing charges a job the costs traceable to it, whole, and
reaches shared costs only by allocation on a stated basis. ASC
340-40-25-7 counts as directly related both the costs traceable to a
contract (25-7(a), (b), (d), (e)) and allocations of costs that relate
directly to it (25-7(c)); 25-8 expenses general and administrative cost.
The books carry the first whole on the document's line and the second as
the allocation convention's own entries; neither is a percentage on the
document (sources/fasb-asc.md, 25-7 and 25-8 added). The handbook's
projects rule and the line's class parameter say the same, and no
handbook sentence lets a shared cost be split across a document's lines.

The accounting: the document's entry posts one revenue (an invoice's) or
expense (a bill's) line per project its lines name, in the order each is
first named, each the sum of that project's lines, and the untagged
lines' sum as one more line (arap::document_parts, conservation checked
by a proptest). A document naming no project therefore posts exactly the
one line every document posted before. The receivable or payable line is
never tagged: it is a balance-sheet line, which item 3 counts nothing;
the payments (receive_payment, pay_bill) move cash against it and take no
project either. Nothing but the projects moves: the P&L, the 1099
worksheet (payments made, B-19) and party totals (what moved the money,
B-35) read the same with or without the tags (twin-books test); the
projects with the untagged lines still partition the P&L.

- ledger-core: DocumentLine.class_id (serde-omitted when none, so old
  documents serialize as before); create_invoice / create_bill split the
  revenue or expense side by project and tag it; an unknown project is
  refused whole (atomically).
- ledger-store: a document line's project is journaled as class_id on
  invoice.created / bill.created, and the entry's line as
  entry.line_class_set right after its entry.line_added (the entry.posted
  lines carry class_id, as a hand-built entry's do). Behind a NEW journal
  feature, document_line_projects (KNOWN_FEATURES, declared by new books,
  asked for before the first journaled line, not even the control
  accounts written on refusal); not `projects`, which the live books
  already declared: the owner consents again at the next upgrade. A
  malformed class_id is corrupt; null or absent is none. Untagged
  documents journal byte for byte as before; old journals replay
  unchanged.
- ledger-mcp: each line takes class (id or name, resolved like
  add_line's, every one before anything is written); the result gains
  notes for a finished or abandoned project, and on an invoice for an
  on-spec project (is there now an agreement? on spec a hoped-for
  payment is no receivable, B-37 item 4), tagged anyway; books lacking
  the feature refuse with format_upgrade_pending. books.get_entry shows a
  line's class_id and project. The handbook's "an invoice or bill takes no
  project yet" caveat now depends on the books: gone where the feature is
  declared, an "until their format upgrade" note where it isn't.
- ledger-gui: an invoice's or bill's page (its entry's) lists the
  document's lines, each project a link that opens it; the demo's client
  invoices are tagged to "Client work", whose snapshot is now its revenue
  less its contractors. Looking at the page in a narrow window found a
  tagged line's tag pushing the amounts past the pane (any tagged entry):
  the name is now cut to leave the tag room, the tag itself at most half
  the cell.
- bookspec: an `invoice` event, and `lines` with `project` on a bill or
  an invoice; example projects-invoice-and-bill-lines-count-by-project,
  worked by hand, both projects client work (Zeta 3,500.00 - 1,200.00 =
  2,300.00; Harbor 200.00;
  untagged -1,750.00; together the P&L's 750.00; Dana's 1099 payments
  1,250.00).
- fuzz: fuzz_store_replay can declare journal features.
- Tests: core, store, MCP, viewer, the P2-served cutover fixture and a
  viewer/server parity test (its month lists the same length, not
  empty); a tagged document's reversal nets its projects to zero, live
  and replayed; books.get_entry's class_id; the handbook served as a
  resource both ways; each fix broken to confirm its test fails
  (docs/testing.md). Docs: rules.md B-27 and B-37 items 3 and 8,
  sources/fasb-asc.md, plan/served.md D-43,
  mcp-interface.md, testing.md, parity.md, plan/STATUS.md.

No proof changed (no kernel arithmetic: document_parts sums with the
existing document_total).

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

docs/mcp-interface.md

@@ -505,7 +505,9 @@ every tool over every book in ledger-store's `tests/fixtures/old-books`.
   schedule); and a reversal of a depreciation run or a schedule month's
   posting (or of a reversal in its chain) dated before that entry's own
   date (a correction comes after what it corrects, B-9).
-- `books.get_entry { entry_id }` → full entry with lines, receipts, and
+- `books.get_entry { entry_id }` → full entry with lines (each `{
+  account_id, code, name, side, amount, class_id?, project? }`: a tagged
+  line's project, its id and name), receipts, and
   its `vendor`, `party_id`, and `party` (the party's label, when it names
   exactly one) tags, `parties` / `parties_error` as in the `post_entry`
   preview, and `no_party_reason` when it is marked as having no
@@ -1980,19 +1982,46 @@ accounting only: the caller supplies every figure), tax filing.
 - `books.add_vendor { name }` → `{ id, party_id }`. Both link the record to
   a party ("Tools — parties").
 - `books.create_invoice { party_id, date, due_date, lines: [{ description,
-  amount }] }` → `{ id, total, entry_id, warnings? }`. Auto-posts Dr
-  `1200` Accounts Receivable / Cr `4000` Revenue. `warnings` names a
-  revenue account it created with no tax category (rules.md B-32).
-  `party_id` is the customer's `id` from `books.add_customer`, not its
-  `party_id`.
+  amount, class? }] }` → `{ id, total, entry_id, warnings?, notes? }`.
+  Auto-posts Dr `1200` Accounts Receivable / Cr `4000` Revenue. `warnings`
+  names a revenue account it created with no tax category (rules.md
+  B-32). `party_id` is the customer's `id` from `books.add_customer`, not
+  its `party_id`. A line's `class` (a project: name or id, resolved as
+  `books.add_line`'s) puts its revenue on that project (rules.md B-37 item
+  8, the owner's decision D-43): one project or none per line, several
+  projects as several lines each with its own amount, never a percentage
+  (a cost truly shared names none: it reaches the projects only as
+  entries of their own under the company's monthly allocation convention,
+  when `books.conventions` has one, and otherwise stays untagged while the
+  agent asks the human). The entry's revenue side is one line per project named, in the
+  order each is first named, the untagged lines' as one (a document
+  naming none posts the one revenue line it always did); the receivable
+  line is never tagged. Every project is resolved before anything is
+  written (an unknown one is refused, the document whole). `notes`: one
+  per finished or abandoned project named, as `books.add_line`'s `note`,
+  and one per on-spec project named, asking whether there is now an
+  agreement (on spec, a hoped-for payment is no receivable until
+  received: B-37 item 4) (tagged anyway). Books that haven't declared the journal feature
+  `document_line_projects` (B-27; the live books until their owner's next
+  upgrade, D-39) refuse a line naming a project with
+  `format_upgrade_pending`, journaling nothing; a document naming none is
+  taken as before.
 - `books.create_bill { party_id, date, due_date, lines }` → `{ id, total,
-  entry_id, warnings? }`. Auto-posts Dr `6999` General Expenses / Cr
-  `2000` Accounts Payable; `warnings` as for invoices. `party_id` is the
-  vendor's `id` from `books.add_vendor`, not its `party_id`.
+  entry_id, warnings?, notes? }`. Auto-posts Dr `6999` General Expenses /
+  Cr `2000` Accounts Payable; `warnings` as for invoices. `party_id` is
+  the vendor's `id` from `books.add_vendor`, not its `party_id`. A line's
+  `class` puts its cost on that project, as an invoice's its revenue: one
+  expense line per project, the untagged lines' as one, the payable line
+  never tagged; `notes` as for invoices, but none for an on-spec project
+  (a cost of on-spec work is an expense like any other); the feature as
+  for invoices.
 - `books.receive_payment { document_id, date, amount, cash_account }` →
-  `{ entry_id, remaining, status }`. Posts Dr Cash / Cr A/R.
+  `{ entry_id, remaining, status }`. Posts Dr Cash / Cr A/R, neither line
+  tagged with a project (balance-sheet only: the invoice's lines carry
+  its projects).
 - `books.pay_bill { document_id, date, amount, cash_account }` →
-  `{ entry_id, remaining, status }`. Posts Dr A/P / Cr Cash.
+  `{ entry_id, remaining, status }`. Posts Dr A/P / Cr Cash, neither line
+  tagged with a project.
 - `books.ar_aging { as_of? }` → `{ as_of, rows: [{ name, current, days_30,
   days_60, days_90, days_90_plus, total }] }` (`as_of` omitted: today).
 - `books.ap_aging { as_of? }` → same, per vendor (`as_of` omitted: today).
@@ -2121,14 +2150,11 @@ until the owner upgrades them.
 - `books.record_payout` lines and adjustments take optional `class` (a
   project); its result gains `notes`, one per finished or abandoned
   project tagged, as `books.add_line`'s `note`.
-- An invoice or a bill takes no project yet: `books.create_invoice` and
-  `books.create_bill` post their entry at once with untagged lines, and
-  only a draft's lines take a class (`books.add_line`'s `class`). Link the document to the
-  project (`books.link_attachment` subject kind `project`); when its lines
-  must count in the project's figures, book it as a hand-built entry
-  (`books.draft_entry` + `books.add_line` class) instead, which then is
-  no invoice or bill in the agings (an open item: tagged document
-  lines).
+- An invoice's or bill's lines take a project too (`books.create_invoice`
+  and `books.create_bill`, `class` on a line, rules.md B-37 item 8), in
+  books that declared the journal feature `document_line_projects`; the
+  handbook's projects section says which these books are. Their payments
+  take none.
 - `books.profit_and_loss_by_class { start?, end?, class? }` (omitted dates:
   the fiscal year to date, as every period report) → per-class revenue,
   expenses, net income, plus an unclassified row (only that class's row

docs/parity.md

@@ -37,7 +37,7 @@ No other statuses.
 | A/R invoices + payments + aging | Business → Invoices | done | R-FUTURE-5 |
 | A/P bills + payments + aging | Business → Bills | done | R-FUTURE-5 |
 | Payroll runs (accounting only, no tax tables) + tax remittance | Payroll | done | — |
-| Tracking classes (divisional P&L) | Class tracking | done | — |
+| Tracking classes (divisional P&L) | Class tracking | done | invoice and bill lines take a class too (projects, rules.md B-37 item 8; QBO/Xero class or tracking per line) |
 | CPA handoff package (TB + GL xlsx, P&L + BS pdf, zip) | Reports → export | done | — |
 | Budgets | Budgets | todo | R-FUTURE-6 (declined as bloat) |
 | Scheduled transactions (recurring entries → drafts) | Scheduled txns / Recurring transactions | partial | hand-verified fixture incl. month-end dates; drafts only, by design |

docs/spec/rules.md

@@ -1585,7 +1585,12 @@ value at contribution and the §704(c) method, B-25) and `projects` (a
 `project.set`, a new event type: a class's project facts; an
 `attachment.linked` to the subject kind `project`, which an older version
 would call corrupt; a `decision.recorded` with `projects`, which an older
-version would drop silently: B-37). A command asks for
+version would drop silently: B-37). After P3: `document_line_projects`
+(an `invoice.created` or `bill.created` line carrying `class_id`, its
+project, B-37 item 8; an older version would restore the document without
+it, silently). It is a feature of its own, not part of `projects`: books
+that declared `projects` before it existed wait for their owner's next
+upgrade before a document's line names a project. A command asks for
 the feature it needs (`Store::ensure_feature`) before its first journaled
 line, and only when the line it is about to write uses it, so a write
 refused for waiting on the upgrade journals nothing, never an entry
@@ -2545,8 +2550,12 @@ package). **Checked:** `ledger-core` `tests/tax_capital.rs`;
 a class as a project ... Projects are entities too and can have name,
 description, whatever other metadata you think they should have"; the
 convention `link-to-projects` in the books: "whenever applicable, we link
-things to [projects]"); CONVENTION (job costing, item 3; the snapshot, item 7: a presentation choice from management accounting, not GAAP); AUTHORITY (on
-spec, item 4: ASC 450-30-25-1; ASC 340-40-25-5 with B-22;
+things to [projects]"); DECISION (the owner, 2026-10-22, plan D-43: an invoice's or bill's
+lines take a project, each line one or none, item 8); CONVENTION (job
+costing, items 3 and 8; the snapshot, item 7: a presentation choice from
+management accounting, not GAAP); AUTHORITY (on
+spec, item 4: ASC 450-30-25-1; ASC 340-40-25-5 with B-22; directly
+related costs, item 8: ASC 340-40-25-7;
 `sources/fasb-asc.md`, both quoted through Deloitte's DART roadmaps and
 not yet re-read in the ASC basic view: an open item)
 
@@ -2582,8 +2591,10 @@ not yet re-read in the ASC basic view: an open item)
    such line through the day, from the first day the books keep, whatever
    the project's dates. A tagged balance-sheet line counts nothing (an
    asset bought for it counts as it is depreciated or expensed, tagged
-   then). No cost is allocated: a shared cost counts only as split across
-   lines when it is entered. The projects with the untagged lines
+   then). The books allocate no cost: a shared cost counts toward
+   projects only as allocation entries of their own, made by the
+   company's allocation convention (item 8). The projects with the
+   untagged lines
    partition the P&L. By month, the period's last 240 months at most.
 4. **On spec.** Work done hoping to be paid: its costs are expenses when
    incurred (B-22; ASC 340-40-25-5 makes a cost of an anticipated
@@ -2595,8 +2606,9 @@ not yet re-read in the ASC basic view: an open item)
    same). Its unrecovered cost, "if repaid", is expenses less revenue to
    date, never below zero: a figure, never an asset.
 5. **Status.** Finished and abandoned projects still take lines (a late
-   cost, a final invoice); `books.add_line` and `books.record_payout` say
-   so when one is tagged.
+   cost, a final invoice); `books.add_line`, `books.record_payout`,
+   `books.create_invoice` and `books.create_bill` say so when one is
+   tagged.
 6. Omitted dates mean what B-30 says (`books.project`'s period); to date
    is always stated as such, beside it.
 7. **Snapshot (a presentation choice, not GAAP).** A project's net is
@@ -2625,6 +2637,52 @@ not yet re-read in the ASC basic view: an open item)
    standard defines or requires these figures (ASC 280's segment
    reporting is for public entities' operating segments, not projects);
    they come from item 3's, one function the tools and the viewer share.
+8. **Invoices and bills (the owner's decision, 2026-10-22, D-43).** Each
+   line of an invoice or bill names one project or none. A document that
+   spans N projects is N lines, each with its own amount; there is no
+   percentage split, so every figure is exact, as entered, with nothing
+   to round. A cost truly shared among projects is not split on the
+   document: its line names none, and it reaches the projects, if at
+   all, only as allocation entries of their own, on the stated basis of
+   the company's monthly allocation convention when `books.conventions`
+   has one; without one the line stays untagged and the agent asks the
+   human. The reasoning: job costing (item 3) charges a job the costs
+   traceable to it, its direct costs, whole, and reaches a shared
+   (indirect) cost only by an allocation on a stated basis, never by
+   guessing at the document. ASC 340-40-25-7 counts as relating
+   directly to a contract (25-5(a)) both the costs traceable to it
+   (direct labor and materials, costs explicitly chargeable to the
+   customer, costs incurred only because of the contract, such as
+   subcontractors: 25-7(a), (b), (d), (e)) and allocations of costs that
+   relate directly to the contract or its activities (25-7(c)); 25-8
+   sends general and administrative costs to expense unless the contract
+   makes them chargeable to the customer (`sources/fasb-asc.md`). The
+   books carry the first kind whole on the document's line and the
+   second as entries under the allocation convention on its basis;
+   neither is a percentage on the document, and 25-7(c) is what the
+   allocation convention models. An invoice line naming an on-spec
+   project (item 4) is taken, and the tools ask whether there is now an
+   agreement: on spec, a hoped-for payment is no receivable until it is
+   received. Its revenue (an
+   invoice's) or cost (a bill's) then counts toward the project exactly
+   as a tagged line of a hand-built entry does: the document's entry
+   posts one revenue (expense) line per project its lines name, in the
+   order each is first named, each the sum of that project's lines, and
+   the untagged lines' sum as one line (`arap::document_parts`), so a
+   document naming none posts exactly the one line every document posted
+   before. The receivable (payable) line is never tagged: it is a
+   balance-sheet line (item 3 counts it nothing), and so are the
+   payments (`books.receive_payment`, `books.pay_bill`: cash against the
+   receivable or payable), which take no project. Nothing else moves: the
+   P&L, the 1099 worksheet (B-19: payments made) and a party's totals
+   (B-35: what moved the money) read the same with or without the
+   projects; only the projects' figures and the P&L by class differ. A
+   line naming a finished or abandoned project is taken, and the tools
+   say so (item 5); one naming a project the books don't have is refused,
+   the document whole. Journaled as the line's `class_id` in
+   `invoice.created` or `bill.created` and an `entry.line_class_set` right
+   after its revenue or expense line's `entry.line_added`, behind the
+   journal feature `document_line_projects` (B-27).
 
 **Enforced:** `ledger_core::classes::{ProjectFacts, ProjectStatus,
 ProjectKind}`, `Ledger::{check_set_project, set_project,
@@ -2632,13 +2690,22 @@ replay_set_project, projects_of_party}`, `reports::{project_figures,
 project_to_date, project_entries, contribution_margin_pct}`,
 `ProjectToDate::{net, margin_pct, any_tagged}`, `ProjectFigures::{months_net_to_date,
 period_margin_pct, period_lines}`, `kernel::unrecovered_cost`;
-`Store::{add_project, set_project, subject_feature}` (feature
-`projects`); `books.add_project`, `books.update_project`,
-`books.projects`, `books.project`; the viewer's Projects pages.
-**Checked:** `ledger-core` `tests/spec_projects.rs`, `ledger-store`
-`tests/projects.rs`, `ledger-mcp` `tests/spec_projects.rs`, `ledger-gui`
-`tests/projects.rs`; bookspec `projects-net-is-its-tagged-lines` and
-`projects-on-spec-costs-are-expenses`; Kani `unrecovered_cost_laws`;
+`arap::document_parts`, `Ledger::{create_invoice, create_bill}` (item
+8); `Store::{add_project, set_project, subject_feature}` (feature
+`projects`), `Store::{create_invoice, create_bill}` (feature
+`document_line_projects`); `books.add_project`, `books.update_project`,
+`books.projects`, `books.project`, `books.create_invoice` and
+`books.create_bill` (`class` on a line); the viewer's Projects pages and
+an invoice's or bill's page (each line's project).
+**Checked:** `ledger-core` `tests/spec_projects.rs` and
+`tests/spec_document_projects.rs`, `ledger-store` `tests/projects.rs` and
+`tests/document_projects.rs`, `ledger-mcp` `tests/spec_projects.rs`,
+`ledger-gui` `tests/projects.rs`, `ledger-cli` `tests/projects_parity.rs`
+and `tests/format_upgrade.rs` (`books_p2_served_cut_over_whole`); bookspec
+`projects-net-is-its-tagged-lines`,
+`projects-on-spec-costs-are-expenses` and
+`projects-invoice-and-bill-lines-count-by-project`; proptest
+`prop_document_parts_partition_the_total`; Kani `unrecovered_cost_laws`;
 proptests `prop_project_nets_partition_the_pnl`,
 `prop_project_set_round_trips`, `prop_project_contribution_is_the_net_to_date`
 (core) and `prop_snapshot_contribution_is_the_net_to_date` (viewer).

docs/spec/sources/fasb-asc.md

@@ -274,3 +274,32 @@ performance obligations in the future; and they "are expected to be
 recovered."
 → B-37 item 4 (with B-22): on-spec work has no contract it is expected
 to recover its costs from, so its costs are expensed as incurred.
+
+## 340-40-25-7 (Costs that relate directly to a contract)
+
+Added 2026-10-22 for B-37 item 8 as the DART revenue roadmap sets it
+out; not re-read in the ASC basic view: check it there at the next
+reading. The costs that "relate directly to a contract" (25-5(a)) are
+(a) direct labor, (b) direct materials, (c) allocations of costs that
+relate directly to the contract or its activities (supervision,
+insurance, depreciation of the tools used on it), (d) costs explicitly
+chargeable to the customer, and (e) other costs incurred only because
+the entity entered into the contract (payments to subcontractors, for
+one). Allocations are among the directly related costs, not set apart
+from them.
+
+## 340-40-25-8 (Costs expensed when incurred)
+
+Added 2026-10-22 with 25-7, from the same DART chapter (13.3), likewise
+to check in the basic view. Expensed when incurred: general and
+administrative costs (unless explicitly chargeable to the customer under
+the contract), costs of wasted materials, labor or other resources not
+reflected in the contract's price, costs that relate to satisfied (or
+partly satisfied) performance obligations, and costs the entity cannot
+tell apart between satisfied and unsatisfied obligations.
+→ B-37 item 8 (with 25-7): a cost traceable to one job (25-7(a), (b),
+(d), (e)) is that job's, whole, on the document's line; a cost that
+relates to several jobs reaches them only by an allocation on a stated
+basis (25-7(c)), which the books record as the allocation convention's
+own entries, never as a percentage on the document; general and
+administrative cost (25-8) is company overhead, no project's.

docs/testing.md

@@ -2028,6 +2028,116 @@ fail.
 rounding strategy; `project_figures`' opening net and running sum;
 `profit_and_loss_counted`'s counts; `Standing::of`'s order.
 
+## Invoices and bills take a project (2026-10-22)
+
+rules.md B-37 item 8: each invoice and bill line takes an optional project
+(`books.create_invoice` / `books.create_bill` `class`); the entry's revenue
+or expense side is one line per project (`arap::document_parts`), the
+receivable or payable and the payments untagged; journaled as the line's
+`class_id` behind the new feature `document_line_projects` (B-27).
+
+- **ledger-core:** `tests/spec_document_projects.rs`
+  (`an_invoices_revenue_is_one_line_per_project_and_the_receivable_none`,
+  `a_bills_cost_is_one_line_per_project_and_the_payable_none`,
+  `an_untagged_document_posts_as_before`,
+  `a_line_naming_an_unknown_project_is_refused_whole`,
+  `a_finished_project_still_takes_an_invoice`,
+  `tags_move_only_the_project_figures` (twin books, tagged and not: the
+  P&L, the 1099 worksheet and a party's activity identical; the projects
+  with the untagged lines partition the P&L),
+  `document_parts_refuse_past_exact_arithmetic`,
+  `reversing_a_tagged_document_takes_its_projects_to_zero` (a partial
+  payment moves no project figure; the reversal carries each line's
+  project, so every project nets to zero), and the proptest
+  `prop_document_parts_partition_the_total`); bookspec
+  `projects-invoice-and-bill-lines-count-by-project` (the loader gains an
+  `invoice` event and a document's `lines` with `project`; loader tests
+  `a_document_line_naming_an_unknown_project_is_refused`,
+  `a_document_with_an_amount_and_lines_is_refused`,
+  `an_invoice_lines_project_is_what_the_project_counts`).
+- **ledger-store:** `tests/document_projects.rs`
+  (`a_tagged_invoice_journals_each_projects_line_and_replays`: the exact
+  lines, then verify, reopen and the viewer's snapshot;
+  `a_tagged_bill_tags_its_expense_lines_never_the_payable`;
+  `an_untagged_document_journals_as_before`: no `class_id` anywhere;
+  `a_document_naming_a_project_waits_for_the_feature`: books with
+  `projects` but not this feature refuse, journaling nothing, not even
+  the control accounts; `old_invoices_and_bills_replay_unchanged`: an
+  earlier version's journal opens, verifies, writes nothing;
+  `a_document_lines_class_id_that_isnt_an_id_is_corrupt`;
+  `a_reversed_tagged_invoice_replays_with_its_projects_at_zero`: one
+  `entry.reversed`, its replay tagged as live); `format.rs`
+  `document_line_projects_is_its_own_feature`.
+- **ledger-mcp:** `tests/spec_projects.rs`
+  (`invoice_and_bill_lines_count_toward_their_projects`: by name, id and
+  any capitals; `books.get_entry`'s line `project` and `class_id`;
+  payments untagged;
+  `books.project`, `profit_and_loss_by_class`, `vendor_1099` and
+  `books.party` totals; `a_document_naming_an_unknown_project_is_refused_whole`,
+  `a_document_for_a_finished_project_says_so`,
+  `an_invoice_for_an_on_spec_project_asks_about_an_agreement` (an
+  invoice's note, a bill's none),
+  `books_without_the_feature_refuse_a_tagged_document` with the
+  handbook's text both ways, by `books.handbook` and as the
+  `books://handbook/projects` resource); `handbook.rs`
+  `document_projects_follow_the_books_feature` (no sentence lets a shared
+  cost be split on a document; the allocation convention only when
+  `books.conventions` has one).
+- **ledger-gui:** `tests/projects.rs`
+  (`an_invoice_and_a_bill_show_each_lines_project`: each document line's
+  project a link that opens it, untagged lines bare;
+  `the_demos_client_work_counts_every_client_invoice`);
+  `pages::entry::tests::a_tagged_line_keeps_its_amounts_in_their_column`
+  (in a narrow pane a tagged line's name is cut to leave its tag room:
+  looking at the demo's invoice page at 1,100 points found the tag pushing
+  the credit column past the pane, a fault every tagged entry had);
+  `tests/screens.rs` shoots an invoice's and a bill's page.
+- **ledger-cli:** `tests/projects_parity.rs`
+  (`invoiced_and_billed_project_figures_are_the_same_in_the_viewer_and_from_the_server`:
+  made through the server's tools, read by both, the month lists the same
+  length and not empty); `tests/format_upgrade.rs`
+  `books_p2_served_cut_over_whole` refuses a tagged invoice and bill
+  before consent and takes them after.
+- **fuzz:** `fuzz_store_replay` can now declare features (this one
+  among them), so a document line's `class_id` reaches replay under a
+  declared format.
+
+**Broken to confirm (each restored):** the core's revenue/expense line
+left untagged (core 4 and store 3 tests fail); `document_parts` one part
+per line (4 core, the proptest among them); the store's feature check
+dropped (store gate test, MCP `books_without_the_feature_...`, CLI
+`books_p2_served_cut_over_whole`); `document_line_json` without
+`class_id` (3 store); `parse_document_lines` ignoring it (4 store, the
+corrupt-id test among them); the `entry.line_class_set` not journaled (3
+store, by verify); the MCP ignoring a line's `class` (4 MCP); no late-tag
+notes (1 MCP); the handbook ungated (the handbook unit test and 1 MCP);
+the handbook's rule without the owner's decision of D-43 (one project or
+none a line, no percentage, a shared cost by the allocation convention:
+the handbook unit test);
+`books.get_entry` without `project` (2 MCP, the CLI parity test); the
+viewer's document lines dropped, or their project not a link (the GUI
+tests); no room kept back for the tag (the narrow-pane test); the demo's invoices untagged (the demo test); the bookspec loader
+dropping a line's project (`every_bookspec_example_holds`). After
+review: the projects handbook's old "split a shared cost across lines"
+sentence restored, or the convention made unconditional (the handbook
+unit test); no on-spec note, or one on a bill too (the on-spec MCP test);
+the handbook resource served as if the feature were declared
+(`books_without_the_feature_...`); `books.get_entry`'s `class_id`
+dropped (`invoice_and_bill_lines_...`); the server's months cut short
+(the parity test, which `zip` alone let pass); a reversal's line tags
+dropped (the core and store reversal tests); the bookspec's Harbor made
+on spec again (`every_bookspec_example_holds`). A separate
+up-front unknown-class check in the core was removed: equivalent to
+`set_line_class`'s own refusal inside `atomically`.
+
+**For P12 (mutation targets):** `document_parts` (the first-appearance
+order, the `contains` test); `add_document_parts`' tag index;
+`ensure_document_lines`' `any`; `document_line_json`'s `if let`;
+`parse_document_lines`' arms (null, absent, out of `u32`);
+`document_notes`' dedup and its `invoice` flag; `on_spec_invoice_note`'s
+kind test; `document_projects_rule`'s branch; the viewer's
+`document_of` (invoice before bill).
+
 ## Benchmarks (baseline 2026-10-13)
 
 No budget, by decision (the owner, 2026-10-13: the books do little work