ledger: any authenticated principal can read and write any book

[Yaraslaut]

Summary

ledger has no per-book ownership or authorization of any kind. Any principal
holding a valid token may read, write and post into any book in the
database, including one another principal created. There is no role table, no
owner column, and no action that consults either.

This is not new — it has been true since the rung shipped — but morph#361's
CreateLedger makes it reachable in a new way: a client can now create a book
over the wire, and the book it creates is immediately writable by every other
authenticated client.

What is enforced, and what is not

Enforced (examples/ledger/include/ledger/auth/ledger_authorizer.hpp's own
file comment is accurate about this):

• SigningAuthorizer::authorize() verifies a real signed token on every
  execute other than AuthModel/Login.
• Each mutating model action refuses an empty principal
  (EmptyPrincipalError), and RunReportJob refuses any principal but
  kReportRunnerPrincipal.

Not enforced: which principal a book belongs to. LedgerModel::execute(const OpenAccount&) checks only that the ledgers row exists;
execute(const GetLedger&) is a pure read with no principal check at all.
authorizeInstance is left at its permissive default, and the authorizer's
file comment gives the reason — LedgerModel's instances are keyed by
ledgerId and shared across every client that opens the same book, so there
is "no single owning caller for authorizeInstance to compare against".

Verification status

Reproduced over the wire on this branch (scenario-corpus-both-axes, with
morph#361's CreateLedger applied), against ladder_ledger_server on a fresh,
unseeded LEDGER_DB. Real output:

  ok   step 5 (line 11) [abooks] do CreateLedger name="Alice's private book"
       capture book = 1
  ok   step 6 (line 14) [abooks] do OpenAccount ledgerId=$book name="Alice Cash" kind=0 currency=1
       capture acash = 1
  ok   step 8 (line 19) [auth] do Login username=bob
       capture bob = bob
  ok   step 11 (line 27) [bbooks] do GetLedger ledgerId=$book
  ok   step 12 (line 31) [bbooks] do OpenAccount ledgerId=$book name="Bob's account in Alice's book" kind=1 currency=1
       capture bacct = 2
  ok   step 14 (line 36) [anon] do CreateLedger name="No token"

Bob reads Alice's book (GetLedger asserts accounts ~ "Alice Cash") and
writes into it (OpenAccount returns id 2 in Alice's book). The last step
confirms the boundary that does hold: a tokenless client is refused with
unauthorized.

Not verified: whether this was a deliberate scope cut. The authorizer's
file comment argues for leaving authorizeInstance permissive, but it argues
from "the model's instances are shared" — which is about instance ownership,
not about book ownership, and says nothing about GetLedger having no
principal check. I could not find a spec statement either way;
docs/superpowers/specs/2026-08-19-ledger-rung5-design.md §11 covers the
empty-principal gate and no more.

Not verified: whether a fix belongs at the authorizer or in each model
action. kanban's answer (a project_roles table plus a requireRole() helper
consulted by every action) is the closest precedent in the ladder, but it is a
schema change plus a gate on every ledger action, not a one-line fix.

Why record it rather than shrug

The rung's whole subject is money and an audit trail. "Any signed-in user may
post entries into any book" is the kind of gap that is invisible from inside
the test suite, because every test uses one principal and one book, and it is
now the first thing a second client of a freshly created book can do.

What would close this

Either a per-book authorization gate (an owner or a role table consulted by
LedgerModel/BudgetModel/RuleModel, kanban-style), or a sentence in
examples/ledger/README.md and the design spec stating plainly that this rung
models one trusted user and shares every book between all of them, so nobody
reads the empty-principal check as an ownership check.

[Yaraslaut]

Triage: rescope — the gap is real, but the ladder's own rules already answer both of the questions this issue leaves open

Premise: confirmed by reading. LedgerAuthorizer's file comment is accurate about what it enforces and honest about what it does not — it names the trust boundary as signed-token auth plus per-action empty-principal and runner-principal checks, and nothing about which principal a book belongs to. execute(GetLedger) validates ledgerId and no principal. There is no owner column on LedgerRecord and no action consults one. The over-the-wire reproduction in the issue is consistent with all of that.

The "either enforce or document" framing is what should be rewritten

The issue lists two resolutions on equal footing and records two "not verified" items. Both are already settled by documents in the tree:

Where the fix goes. examples/IMPLEMENTATION.md rule 4:

Relations use BelongsTo/HasMany with declared foreign-key constraints, and ownership authorization is expressed through the relation (bank's loadOwned pattern), not by string-building WHERE clauses.

and rule 1:

Models must re-check their own preconditions and authorization (Context::principal) — the schema's required and the client gates are UX, not security.

So: in the models, through the relation — not at the authorizer. That also confirms the authorizer comment's own reasoning is not a scope cut but a correct observation about the wrong hook: authorizeInstance compares one recorded register-time owner against the caller (docs/spec/security.md, "The per-instance ownership hook"), which cannot express "this book has an owner" for instances keyed by ledgerId and shared across clients.

Whether it was a deliberate scope cut. Rung 1 already implements exactly this pattern for exactly this domain — examples/bank/include/bank/db/ledger_ops.hpp:63-94:

if (std::string{rec->user->username.Value().str()} != owner) {
    throw Unauthorized{std::string{noun} + " belongs to a different owner"};
}

loadOwned / loadOwnedOpenAccount are described there as "the single home for the 'owned and open' rule that every money-movement path shares". bank is the rung IMPLEMENTATION.md names as the shape to follow, and it is the same subject matter — money and an audit trail. Rung 5 having no equivalent is a gap against the ladder's own convention, not a documented simplification.

That does not make the documentation route illegitimate — "this rung models one trusted user" is a decision the repo owner can take. But it is not the equal of the enforcement route, and writing it would need the same kind of explicit justification rule 2 demands for a hand-built GUI, naming rule 4 and saying why rung 5 sits behind rung 1 on it. Rewrite the issue around that asymmetry.

Two things to fold into the rewrite

• It is the reads as much as the writes. GetLedger is a pure read with no principal check, and morph#371 notes GetReportStatus takes a jobId and no ledgerId at all. A per-book gate that covers only mutations leaves both.
• Sequencing with morph#361. CreateLedger is where an owner principal first becomes available to record at creation time, so the owner column and CreateLedger want to land together; otherwise every pre-existing book needs a backfill decision.

Keeping bug: this is a defect in shipped behaviour of a rung whose stated subject is money, not a missing feature.

What would change this verdict: a design-note or spec statement predating the rung that scopes it to a single trusted user. docs/superpowers/specs/2026-08-19-ledger-rung5-design.md §11 covers the empty-principal gate only, and I found nothing else — consistent with the issue's own search.