Batch acceptance invocations over enumerated, manifest-pinned selections

[Hafeok]

Implement ledger accept --group|--set to batch the invocation over a selection while preserving the binding semantics of acceptance. Each decision in the selection receives its own acceptance record signing its own version hash, exactly as a single accept would produce.

Summary

This change adds batched acceptance as an ergonomic affordance for signing multiple decisions in one pass. The key insight is that batching the act (filing multiple acceptances together) is different from batching the signature (one record covering multiple decisions). This implementation preserves the latter's semantics: every acceptance is scoped to its own version hash, and the selection is pinned by a manifest digest that must match between the read (dry run) and the write (confirmation).

Key Changes

• New batch module (ledger-core/src/batch.rs): Core abstraction for enumerated, pinned selections

  • Plan struct: enumerated members with their standing (signable, held, already-signed, forked) and a manifest digest
  • Outcome struct: result of an invocation (dry run or signed, with optional refusal)
  • Member struct: one decision with its version hash, state, and standing
  • manifest() function: domain-separated digest over (selector, actor, members) triples including standing

• New batch_drift module (ledger-core/src/batch_drift.rs): Drift detection and recovery

  • locate(): recovers the selection a manifest was taken over by replaying log prefixes
  • changes(): names what moved between two selections (entries added/removed/revised/restated)
  • Enables refusals to say which decision changed, not just "the selection moved"

• New batch_render module (ledger-core/src/batch_render.rs): Terminal rendering

  • render(): formats the enumeration, tally, and verdict as a pasteable block
  • Separates layout from the Outcome struct so --json and text cannot drift

• New hold module (ledger-core/src/hold.rs): Held entries that block batches

  • Hold struct: a basis pointer in the indeterminate: scheme and the reason it blocks
  • hold(): derives holds from based_on pointers, not hand-listed
  • A held member stops the whole batch by name, so the judgment stays recorded

• New group_accept module (ledger-core/src/author/group_accept.rs): Batched acceptance logic

  • accept_group(): enumerates the selection, pins it with a manifest, and optionally signs it
  • Default posture: dry run (enumerate, print, write nothing)
  • Confirmation posture: --confirm <manifest> signs only if the store still enumerates to that manifest
  • Per-member gating: each acceptance is gated individually, so a member that would fail as a single accept fails the batch with the same class and message
  • Three refusals: held/forked members, manifest drift, and gate violations

• CLI adapter (ledger-cli/src/commands/sign.rs): Two shapes of accept over one meaning

  • AcceptFlags struct: decision (single) vs. set/group (selection) vs. confirm (manifest)
  • Naming a decision signs it immediately (existing behavior)
  • Naming a selection enumerates it, prints it, writes nothing (dry run)
  • --confirm <manifest> signs the selection if it still matches that manifest
  • --json output for both shapes

• Selector canonicalization (ledger-core/src/show.rs): Selector::to_string() for manifest digests

  • Canonical spelling so selectors can go inside manifests without a second serialization

• Comprehensive test suite (ledger-cli/tests/accept_group.rs): 380 lines of end-to-end scenarios

  • Batching files one acceptance record per decision, each on its own hash
  • Dry run is the default posture and writes nothing
  • Confirmation without a

https://claude.ai/code/session_01FwsbsqP5nqVPjkjZFzmH7b