Implementation Contracts

Implementation work should follow the canonical contracts defined in the truth section.

Security implementation slice

The developer test identity slice should implement security behavior as ordinary domain and application behavior:

place actor, role, permission, protected-action, and policy logic under BooksPlus.Domain.Security;
place append-only audit event contracts under BooksPlus.Domain.Audit;
pass actor, company, protected action, target, and correlation context through application services according to the company contract;
use the persisted company model for BooksPlus Test Company; do not rely on an implicit default company for protected work;
seed BooksPlus Test Company, Developer Test User, and Developer Test Full Access only in explicit development/test mode;
generate the development/test full-access bundle from the protected action registry;
reject protected commands that cannot resolve required actor and company context before domain mutation;
record the resolved company identifier on company-scoped audit events.

The first accounting posting foundation should implement the accepted posting ADR as ordinary accounting domain and application behavior:

place account, journal-entry, money, and posting policy behavior under the accounting/shared domain areas named by the architecture guidance;
expose one central posting service for routine posting rather than allowing screens, imports, close, or feature-specific components to persist ledger effects directly;
enforce active-account, balanced-entry, same-currency, source-reference, explanation, attribution, and financial-period eligibility rules before persistence;
treat entries created in this slice as posted-only records;
use journal_entry.post as the protected action name for routine posting;
emit an attributable audit event for successful and rejected consequential posting attempts according to the security audit contract;
defer draft journal entries, human-visible numbering, reversals, adjustments, close adjustments, and automated-posting idempotency until their own accepted slices define the behavior.

The chart of accounts implementation should keep account maintenance around the accounting kernel:

preserve immutable account ids on journal lines;
treat codes as strings and preserve leading zeros;
never infer accounting behavior from account-number patterns;
resolve account entry by exact code before optional chart-level shorthand padding;
reject inactive, retired, non-posting, wrong-company, and ambiguous accounts with structured results;
install starter chart definitions idempotently;
enforce semantic-role cardinality through explicit role assignments;
record material account changes in account history and protected audit events;
stage chart imports for review and validation before committing accounts.