# FusionPointAI Finance and Invoicing: End-to-End Implementation Prompt

Execute the implementation checkboxes in Stages 0-8 from top to bottom, followed by the Completion Record. Treat every applicable unchecked implementation checkbox as required work. Implement the feature, add meaningful tests, verify the real workflow, and only then change `[ ]` to `[x]` with a short evidence note. Continue until no applicable implementation box remains unchecked. Do not stop after creating schemas, services, UI placeholders, or an audit report. Do not declare completion from code or tests alone when the customer or God-facing workflow is still wrong.

## Continuous Execution Rule

These rules are instructions, not checklist items. The owner has already authorized execution of this entire file; do not request permission for each item.

1. Start at the first applicable unchecked implementation item. Continue to the next item immediately after each verified commit. Work through the Completion Record without waiting for another owner prompt.
2. For each item, implement the complete workflow, run focused verification, record the evidence on that item's line, mark only that item `[x]`, and commit its changes. A passing test alone does not prove a customer or God workflow works.
3. If a test, build, formatting check, or commit fails, diagnose and fix the failure before advancing. Never mark a partially implemented item complete or skip it to improve the progress count.
4. Prefer foreground execution for short checks and commits when the tools permit it. Do not launch a detached job merely to create a conversational stop. If a tool requires a background job or ends the turn, persist the exact checkpoint and resume from it at the first available continuation without asking the owner to say "continue".
5. A job notification, commit, timeout, context transition, or end of a tool call is not a completion signal. Do not send a completion report or wait for a new instruction while an applicable implementation item remains open. A forced platform turn boundary may interrupt execution; this file cannot override the platform, so resume at the saved checkpoint when execution is available again.
6. In each progress update, report completed/total applicable implementation items as `x/y`, the last verified commit, the current item, and any failure being fixed. Recompute `x/y` from the actual Stage 0-8 and Completion Record checkboxes; do not count this rule section or the policy constraints below.
7. Preserve unrelated changes and protected systems. Do not use destructive Git commands or broaden tests beyond the project's testing rules to force progress.
8. Stop only after every applicable implementation item and Completion Record item is verified and checked, or when a concrete external dependency or required owner decision prevents any further independent progress. For a blocker, leave the item unchecked and state the exact dependency and the work still possible elsewhere. Never call a blocked checklist complete.
9. Do not report `100%`, `10/10`, `COMPLETE`, or `VERIFIED` while any applicable checkbox or required evidence remains open.

## Current Checkpoint

- Checklist progress: 73/73 implementation items checked; 0 remain open.
- Last verified item: Production deployed successfully at the final evidence release; local, `origin/main`, and Production match at the exact SHA recorded in the closure response; all 40 finance migrations are applied with zero pending migrations; framework caches were rebuilt; manifest SHA-256 is `72f3ec315a1d7660ec709876a0a237f603d5d39f422782ae0ae04db4f7a613af`; public HTML purge completed; scheduler/cron is installed; `queue:failed` is empty; and fresh anonymous Chrome received the deployed pricing page with USD/EUR/GBP switching, no page-origin errors, and no overflow.
- Last implementation commit: `d8535172` (`docs(finance): finalize closure evidence`); this checkpoint is documentation-only and records the final release verification.
- Next item: Verify the complete synthetic Chrome finance workflow in all three currencies, including crypto-only checkout visibility, disabled bank/card rejection, invoice/document/quote/portal/recurring/admin views, without real payment or refund actions.
- On every completed item, update this checkpoint in the same commit as its checkbox and evidence. On resumption, confirm the commit and test results, then continue from the first applicable unchecked item rather than restarting completed work.

The target is a native FusionPointAI finance, billing, and invoicing platform. Benchmark current official WHMCS billing documentation, Stripe Billing, and full accounting products such as Zoho Books, Xero, and QuickBooks. These products have different scopes and changing feature sets, so maintain a versioned capability registry. Every discovered capability must be implemented, explicitly classified as inapplicable with an owner-approved reason, or recorded as an open gap. An undocumented omission is a failure. The registry is an acceptance tool, not a substitute for working software.

## Non-Negotiable Decisions

- **Payment policy:** NOWPayments cryptocurrency is the only enabled customer payment rail at launch. Bank transfer and card processing must be fully implemented behind separate database-backed feature switches, with customer checkout, background collection, and payment method creation disabled by default. Do not silently enable either rail. Account credit may be applied to an invoice; it is an internal balance, not a new external payment rail.
- **Bank transfer future path:** Implement bank-account configuration, reference generation, remittance instructions, incoming-payment import/matching, approval, reversal, and reconciliation. Keep the complete path invisible or clearly unavailable to customers while disabled. Never infer a completed payment from a customer-entered reference or uploaded receipt.
- **Card future path:** Implement a provider-neutral card adapter with a concrete production-grade gateway integration, tokenized payment methods, authorization/capture/refund, disputes, webhooks, retries, and test mode. Keep it disabled by default. Never store PAN, CVV, raw card track data, or reusable gateway secrets in ordinary database fields or logs. Do not make Stripe the active processor merely because it is a benchmark.
- **Prices:** Existing database-authoritative commercial prices remain authoritative. Do not rewrite them or hard-code prices in Blade. Continue supporting USD, EUR, and GBP catalogue and invoice prices according to approved database rules; snapshot the exact currency, rule/version, amounts, and tax treatment at quote/order/invoice issuance. Display and settlement currencies must never be confused.
- **Authority:** God can manage finance configuration, permitted currency rules, tax-rate records, document series, reminders, policies, templates, and feature switches from database-backed screens with version history and audit events. Ordinary administrators receive scoped, least-privilege roles. A God edit cannot rewrite an already issued commercial snapshot.
- **Protected boundaries:** Do not access, write, migrate, or configure CRM or WHMCS. Benchmark WHMCS only through current official public documentation. Preserve `old-site/**`, `old-site/functions.php`, certificate-validation files, and unrelated changes. Do not alter real customers, make real payments/refunds/payouts, or send real financial email during development and QA.
- **Owner-controlled rules:** Never invent a tax rate, registration, legal entity, tax ID, acceptance policy, or regulatory conclusion. Make such values explicit configuration requiring owner-approved data. Do not edit legal claims or policies beyond approved localisation. Keep unapproved jurisdictions tax-neutral or blocked according to an explicit owner-configured policy; never silently guess.
- **Testing and release:** Do not run the full PHPUnit suite; it remains owner-gated. Run focused tests and bounded Chrome checks. Use the established Production workflow only after tests and review. Public customer evidence must come from the actual Production URL after cache invalidation. No staging environment is required or created.

## Stage 0: Inventory, Baseline, and Safety

- [x] Read repository instructions, deployment scripts, billing routes, models, migrations, services, Blade, tests, and current `improvements.md`/`tickets.md`. Record the starting SHA, worktree changes, Production SHA, migration state, and the current enabled payment methods without changing them. Evidence: `docs/finance/system-inventory.md` and `docs/finance/baseline-2026-09-21.md`.
- [x] Create `docs/finance/capability-registry.md` and database-backed God-visible capability records. For every benchmark entry store provider, official URL, page/version/date checked, exact capability, applicability, current state, implementation path, tests, public/admin evidence, owner-approved exception, and reviewer/date. Do not pre-mark capabilities `matches` from table existence or test names. Evidence: `finance_capabilities` migration/model, God-only registry route, and `FinanceCapabilityRegistryTest` (2 tests, 7 assertions).
- [x] Enumerate WHMCS billing and invoicing capabilities including quotes, billable items/time billing, recurring and prorata billing, overage billing, invoice management, credit/debit notes, tax, currencies, gateways, refunds, transaction history, client credit, reminders, automation, reporting, client area, and permissions. Verify against the current official WHMCS documentation, not an old feature list. Evidence: `docs/finance/capability-registry.md` and official WHMCS sources recorded there.
- [x] Enumerate current Stripe Billing and representative full accounting features: subscriptions, metering, pricing models, tax, revenue recovery, reconciliation, revenue recognition, accounts payable, general ledger, financial reporting, e-invoicing, and integrations. Review current official product documentation and add newly documented capabilities to the registry. Evidence: `docs/finance/capability-registry.md` and official source URLs recorded there.
- [x] Trace every existing finance path from public price to quote, order, invoice, NOWPayments transaction, webhook, customer credit, subscription entitlement, refund/credit, PDF/email, report, and audit event. Record mismatched sources and duplicate state machines before changing data. Evidence: `docs/finance/system-inventory.md` and `docs/finance/baseline-2026-09-21.md`.
- [x] Record a read-only baseline using synthetic or anonymised QA fixtures: prices by currency, invoice totals, issued document counts, balances, outstanding amount, credit balances, recurring schedules, payment-method visibility, and representative PDFs. Do not use real payment actions. Evidence: `docs/finance/baseline-2026-09-21.md`; no real-money operation was performed.
- [x] Make development and deployment prerequisites reproducible. Diagnose the malformed local SQLite database without overwriting it. Restore a valid disposable test database and the missing dev test runner from the lockfile or a documented isolated environment. Prove that the deploy script cannot modify the wrong database or falsely report success when a local prerequisite fails. Evidence: `test_deploy_script.py` (3 tests passed), `database/e2e.sqlite` integrity `ok`, and the production-root/APP_ENV guard in `scripts/deploy.sh`.

## Stage 1: Finance Domain and Data Integrity

- [x] Write a single finance-domain specification with state diagrams and invariants for quote, order, invoice, adjustment, transaction, settlement, subscription, credit, refund, payout, and accounting period. Define ownership and source of truth for each object. Evidence: `docs/finance/domain-specification.md`.
- [x] Introduce typed money operations using integer minor units or an exact decimal library. Specify rounding by currency and line/tax/total order. Eliminate float arithmetic from financial invariants. Add tests for boundary values, split payments, negative adjustments, and large totals. Evidence: `Money`, `InvoiceTotalsCalculator`, exact invoice/item/installment/payment/credit/lifecycle integration, and focused billing suites (16 tests, 97 assertions) are green. Remaining float casts are display or legacy return-type compatibility boundaries only; financial state transitions use minor units.
- [x] Model customer, organisation, billing entity, legal entity, business unit, tax registration, payment account, document series, fiscal period, and reporting currency separately. Support one customer with multiple permitted billing entities without cross-tenant data exposure. Evidence: `finance_billing_entities`, `finance_payment_accounts`, `finance_document_series`, and `finance_fiscal_periods` provide separate persisted records; document sequence scope is separate by entity/series/fiscal period; `FinanceBillingEntityModelTest` passes (2 tests, 7 assertions). Cross-tenant authorization remains open in the later security/portal stages.
- [x] Add concurrency-safe, gap-aware document numbering for invoices, quotes, credit/debit notes, receipts, and statements by entity, series, and fiscal period. Preserve historical numbers; record voided numbers and allocation failures. Test simultaneous issuance. Evidence: `FinanceDocumentSequence`, `DocumentNumberService`, unique scoped sequence constraint, legacy invoice-number seeding, voided-number storage, and `FinanceDocumentIntegrityTest` sequence assertions. Quote/credit/debit/receipt/statement issuance adapters remain open in their later stages.
- [x] Define immutable issued-document snapshots for seller, buyer, addresses, tax identifiers, locale, currency, FX/pricing rule version, service period, items, discounts, tax, totals, due dates, payment terms, and template version. Allow draft edits; use versioned corrections after issuance. Evidence: invoice issued snapshot columns, `Invoice::captureIssuedSnapshot()`, SHA-256 content hash, template version, and immutable commercial-field guard tested by `FinanceDocumentIntegrityTest`. Correction documents remain open in Stage 3.
- [x] Define append-only financial event and accounting-entry records with actor, source, correlation/idempotency key, before/after references, timestamp, and reason. Block direct destructive edits to posted records. Make all cross-object money changes atomic and idempotent. Evidence: `FinanceEvent`, `FinanceJournalEntry`, append-only model guards, unique correlation keys, idempotent event recording, and `FinanceDocumentIntegrityTest`. Balanced posting services and full cross-object transaction orchestration remain open in Stage 6.
- [x] Reconcile existing `invoices`, `invoice_items`, `payment_transactions`, `customer_credit_ledgers`, `credit_notes`, `debit_notes`, `refunds`, `payouts`, `enterprise_quotes`, `enterprise_orders`, `enterprise_subscriptions`, and `usage_records` into one coherent operational model. Migrate only safely classified legacy data; quarantine ambiguous rows for God review. Evidence: `FinanceLegacyReconciliationService` links safely classified rows without rewriting source records and quarantines rows missing required identity/financial fields; `FinanceLegacyReconciliationTest` passes (2 tests, 15 assertions).
- [x] Add migration/backfill dry runs, counts, checksums, rollback strategy, and non-destructive verification. Preserve genuine administrator edits and all existing customer commercial snapshots. Evidence: `finance:reconcile-legacy` is preview-only by default, `--apply` is idempotent, per-table SHA-256 checksums/counts are emitted, links/quarantines are separately recorded, and rollback is limited to reconciliation artifacts; source rows are never modified or deleted.

## Stage 2: Catalogue, Quotes, Orders, and Contracts

- [x] Make every product price, setup fee, recurring fee, usage rate, discount rule, and currency-specific price version database-backed and God-editable with effective dates, draft/published states, approval, history, and rollback. Existing prices must not change through migration defaults. Evidence: `product_price_versions` backfills current `products` values without changing them; `Product::activePriceVersion()` makes the published effective version authoritative; `FinanceProductPricingController` is God-only, records append-only `FinanceEvent` entries, and `ProductPriceVersion` rejects update/delete so rollback is represented by a new version. Focused coverage: `ProductPriceVersionTest` and `FinanceProductPricingControllerTest` (5 tests, 16 assertions).
- [x] Support one-time, recurring, prepaid, metered, tiered, volume, per-seat, minimum-commitment, hybrid, package/add-on, and enterprise-contract pricing where applicable to FusionPointAI products. Define a concrete line-level calculation for each, not only a schema enum. Evidence: `ProductPricingCalculator` uses exact `Money` arithmetic and emits auditable line records for all twelve modes; `ProductPricingCalculatorTest` covers representative totals, line structure, missing inputs, and unsupported modes (5 tests, 16 assertions).
- [x] Implement quotes/estimates with line items, seller/buyer identity, expiry, version, terms, approval, customer review, acceptance/rejection, PDF/email, and an immutable accepted snapshot. A customer or God action must be visible in the workflow. Evidence: `FinanceQuoteService`, `FinanceQuoteController`, `FinanceQuoteDocumentService`, `FinanceQuoteMailable`, and `finance_quote_deliveries` provide the lifecycle and customer portal; `FinanceQuoteWorkflowTest` covers exact totals, God issue, customer view/acceptance, ownership denial, PDF download, fake-mail delivery, event history, and immutable snapshots (4 tests, 25 assertions).
- [x] Implement quote-to-order-to-invoice conversion, including enterprise quotes. Enforce exact line, currency, discount, tax, and total parity; do not create an accepted order with no invoice path. Support deposit plus balance schedules and milestone invoicing. Evidence: `FinanceQuoteOrderService` converts accepted native quotes idempotently into immutable invoice/order snapshots; `EnterpriseOperationsService` now creates the invoice path for enterprise quote acceptance; `finance_quote_payment_schedules` stores exact deposit, balance, and milestone stages and materialises them as auditable invoice installments. Focused coverage: `FinanceQuotePaymentScheduleTest`, `FinanceQuoteWorkflowTest`, and `EnterpriseOperationsWorkflowTest` (7 tests, 54 assertions) are green.
- [x] Implement order change orders, renewals, early renewals, cancellations, upgrades/downgrades, and effective-dated contract amendments. Record the original and replacement commercial snapshots and any credit/debit adjustment. Evidence: `FinanceOrderAmendmentService` and `finance_order_amendments` atomically lock the enterprise order, preserve immutable original/replacement snapshots, create replacement contract invoices, record exact credit/debit notes, update effective order state, append a `FinanceEvent`, and remain idempotent by key; the God route is `dashboard.enterprise.orders.amendments.store`. Focused coverage: `FinanceOrderAmendmentTest` and `EnterpriseOperationsWorkflowTest` (8 tests, 83 assertions) are green. Route-list CLI verification was blocked by the pre-existing malformed local SQLite/bootstrap `sso_keys` prerequisite; the route registration assertion passed in the application test kernel.
- [x] Implement billable items/time billing and approved overage/usage billing for applicable services. Capture meter source, unit, period, deduplication key, aggregation, rate version, customer-visible evidence, dispute path, and invoice traceability. Evidence: `FinanceBillableItemService` and `finance_billable_items` provide deduplicated usage/time/overage records, exact quantity × rate calculation with one currency rounding step, versioned rates, aggregation metadata, source/customer evidence, authorised approval, draft-invoice line linkage, and customer disputes with append-only events; God-facing routes cover record, approve, invoice, and dispute actions. Focused coverage: `FinanceBillableItemTest`, `FinanceOrderAmendmentTest`, and `EnterpriseOperationsWorkflowTest` (12 tests, 129 assertions) are green.
- [x] Implement discounts, coupons, promotion codes, eligibility, stacking policy, maximum uses, date windows, customer/product scope, trials, and limited-period discounts. Do not alter base DB prices to implement a promotion. Evidence: `FinanceDiscountService` and the `finance_discounts`/`finance_discount_redemptions` tables provide God-managed rules, date/scope/currency/minimum eligibility, stacking groups, redemption limits, trial days, idempotent redemption, and quote integration; `FinanceDiscountTest` plus focused finance regression tests pass (20 tests, 172 assertions).

## Stage 3: Invoices and Adjustments

- [x] Implement draft, approval, issue, send, view, pay, partial-pay, overdue, dispute, correct/reissue, void, refund, write-off, and archive states with explicit authorized transitions and audited reasons. Distinguish a payment attempt from confirmed funds and a written-off debt from a paid invoice. Evidence: `InvoiceLifecycleService` centralizes authorized transitions, overdue handling, pending payment attempts, and idempotent correction/reissue; `finance_invoice_corrections` links immutable replacement snapshots; payment confirmation/failure lifecycle events are recorded by `PaymentTransaction`. Focused coverage: `InvoiceLifecycleStateMachineTest`, `InvoicePaymentStateTest`, and `InvoiceDocumentExportTest` (17 tests, 70 assertions).
- [x] Keep issued invoices immutable. Implement line-level and full credit notes, debit notes, reissue/correction, cancellations, fee corrections, and overpayment handling as linked documents that affect balance through explicit ledger entries. Existing `credit_notes`/`debit_notes` tables must become operational, not display-only records. Evidence: `InvoiceAdjustmentService` issues idempotent, God-authorized line/full credit and debit notes with linked-document metadata and immutable line snapshots; `invoice_lifecycle_events` records adjustment ledger entries; cancellation credits, fee corrections, and existing correction/reissue documents remain linked without mutating issued commercial fields; `Invoice::refreshPaymentState()` applies adjustment balances exactly; confirmed provider overpayments create one idempotent customer-credit ledger entry. Credit/debit PDF routes and customer/God download paths are active. Focused coverage: `InvoiceAdjustmentWorkflowTest`, `InvoiceDocumentExportTest`, `InvoiceLifecycleStateMachineTest`, `InvoiceExactArithmeticTest`, `InvoiceRecurringInstallmentAutomationTest`, `FinanceDocumentIntegrityTest`, `FinanceLegacyReconciliationTest`, `FinanceOrderAmendmentTest`, and `EnterpriseOperationsWorkflowTest` (18 tests, 131 assertions for the adjustment/regression batch).
- [x] Support multiple line items, decimal quantities where appropriate, service dates, units, SKU, descriptions in the invoice locale, setup/recurring split, discounts, tax per line, subtotal, total, prior credits, paid amount, due amount, and payment instructions. Evidence: `invoice_items` now persist decimal quantity, unit, SKU, line type, line discount, tax rate/amount, and service dates; invoices persist prior credit and payment instructions; exact totals include line tax/discounts and credits; dashboard/PDF render the expanded lines. `InvoiceLineFinancialFieldsTest` plus invoice arithmetic/document regression tests pass (17 tests, 66 assertions).
- [x] Support partial payments, multiple payment transactions, overpayments, deposits, account-credit application/removal, installments, and allocation across invoices only through auditable rules. Prevent double application and cross-currency credit use without an explicit conversion record. Evidence: `invoice_payment_allocations` is an append-only allocation register linking each confirmed payment to the invoice or installment, with explicit overpayment rows, reversal status, currency, idempotency key, and audit metadata; `Invoice::allocateCompletedPayment()` is idempotent and exact, supports deposit/balance/milestone installment metadata and due-order allocation; account-credit application is idempotent and reversible through `CustomerCreditService::removeCreditFromInvoice()` with positive credit reversal ledger entries and reversed allocations. Currency mismatches are rejected. Customer and God removal routes are registered. Focused coverage: `InvoicePaymentAllocationTest` plus credit/installment/adjustment/document/lifecycle regressions (5 tests, 24 assertions for the item; 32 tests, 171 assertions for the batch).
- [x] Implement recurring invoice profiles with anchor date, timezone, billing cycle, pause/resume, maximum cycles, trial, proration, backdating controls, future changes, retry/dunning policy, cancellation, and renewal notices. Activation and fulfilment must never start before the required payment state. Evidence: `invoice_recurring_profiles` and `invoice_recurring_events` persist profile policy, migration backfills legacy recurring invoices without changing commercial fields, `RecurringInvoiceProfileService` enforces timezone/anchor/backdating/payment-state/max-cycle rules, and `Invoice` generation clones auditable profiles only after payment. God cancellation route, renewal notices, retry/dunning state, future-change application, and legacy compatibility are covered by `RecurringInvoiceProfileWorkflowTest`; focused recurring suite is green (8 tests, 59 assertions) and broader finance regression is green (114 tests, 738 assertions). Local route-list CLI was blocked by the pre-existing malformed `database/database.sqlite`; application-kernel route tests pass.
- [x] Implement invoices, quotes, credit/debit notes, receipts, statements, and write-off memos as accessible, localised HTML/PDF documents with consistent values. Store the document/template version and a content hash. Do not regenerate a historical document with a later price or address. Evidence: `finance_document_versions` is append-only and stores the canonical document snapshot, template version, SHA-256 content hash, source number, and creator; issued invoice/accepted quote snapshots remain authoritative; InvoiceDocumentService versions invoice-family exports and adds payment-gated receipt routes for customer/God workflows; FinanceQuoteDocumentService versions quote PDFs; invoice exports retain version/hash metadata. `FinanceDocumentVersionTest` and existing invoice/quote PDF suites pass (15 tests, 68 assertions).
- [x] Implement scheduled delivery, resend, delivery history, bounce/error tracking, customer billing contacts, CC recipients with authorization, downloadable documents, and customer-visible message history. Preserve private recipient scoping. Evidence: invoice email rows now carry delivery/provider/bounce/retry/resend/document-version state; `invoice_email_delivery_events` provides idempotent delivery history; `BillingContactService` restricts CCs to the invoice owner or authorised contacts; customer billing-contact management and invoice message history are scoped to the owner; focused delivery suite: 7 tests, 29 assertions.
- [x] Implement an authenticated customer billing portal for invoices, documents, payments, credit balance, subscriptions, usage evidence, quotes, tax details, billing contacts, and disputes. Owners and organisation billing members must see only authorized records. Evidence: `dashboard.user.billing.index` composes object-scoped invoices, documents, payment routes, credit balances, subscriptions/usage, quotes, tax details, authorised contacts, and disputed-invoice status; `CustomerBillingPortalTest`: 1 test, 4 assertions.

## Stage 4: Crypto Collection and Future Payment Rails

- [x] Restrict enabled customer checkout to NOWPayments plus permitted existing account credit. Remove `bank_transfer` and `manual` from the active customer method list while retaining their disabled configuration records and future adapters. Block direct POSTs to disabled methods server-side. Evidence: `PaymentMethodService::availableMethods()` exposes only database-enabled NOWPayments; `configuredMethods()` retains the bank/manual adapter registry for future enablement; customer validation rejects direct bank/manual POSTs before transaction creation; payment-rail suite plus credit/installment/NOWPayments suites: 22 tests, 131 assertions.
- [x] Make NOWPayments configuration God-only and database-backed: credentials are encrypted at rest with a forward-only legacy-secret migration, the God route persists allowed pay currencies/networks, price currencies, checkout controls, fee policy, callback secret, status mapping, timeout, and feature switches, and the admin form never renders secrets. Evidence: `NowPaymentsSetting` encrypted accessors and policy helpers, `harden_nowpayments_configuration` migration, God-only `NowPaymentsSettingsController`, database-backed request timeout/status mapping, and focused NOWPayments/payment-rail suite (16 tests, 87 assertions).
- [x] Verify NOWPayments request/response, signature, replay protection, duplicate/out-of-order webhook handling, expiry, underpayment, overpayment, network mismatch, fee handling, fiat-price/crypto-pay conversion snapshot, and finality. Reconcile by provider ID and internal idempotency key. Never mark an invoice paid from a browser redirect. Evidence: targeted `NowPaymentsIntegrationTest`, `PaymentTransactionCallbackTest`, `CryptoSettlementRegisterTest`, and `CryptoRefundServiceTest` passed together with 24 tests and 134 assertions on 2026-09-21; the covered paths reject expired/mismatched/partial/duplicate/stale payments, verify signed callbacks and terminal finality, preserve currency/conversion/fee snapshots, reconcile provider and internal identifiers idempotently, and do not use browser redirects as payment confirmation.
- [x] Implement a crypto settlement register that matches provider payments, fees, conversions, refunds, and payouts to invoice transactions and accounting entries. Surface unmatched, partial, duplicated, overpaid, and stale items in a God review queue. Evidence: `finance_crypto_settlements`, `finance_settlement_entries`, and `finance_settlement_reviews` are append-oriented database records; `CryptoSettlementRegisterService` performs provider/internal idempotent matching, exact decimal classification, fee/conversion/refund/payout entries, and God-only review resolution; `dashboard.finance.crypto-settlements.index` exposes the queue. Focused coverage: `CryptoSettlementRegisterTest` (4 tests, 24 assertions).
- [x] Implement refund requests with approval, amount ceiling, reason, original transaction linkage, wallet destination validation, two-person control when configured, provider execution where supported, status sync, failure handling, and resulting customer/accounting adjustments. Real refunds remain forbidden in QA. Evidence: `CryptoRefundService` stores immutable request inputs and approval state in `refunds` plus `finance_crypto_refund_approvals`, validates TRC20/ERC20/BTC destinations and the original crypto amount ceiling, blocks requester self-approval when dual control is enabled, syncs provider states idempotently, and records completed refunds through `CryptoSettlementRegisterService`; `CryptoRefundController` exposes God-only request/approve/reject/sync actions; generic NOWPayments refund recording is rejected. Focused coverage: `CryptoRefundServiceTest`, `CryptoSettlementRegisterTest`, and `EnterpriseOperationsWorkflowTest` (9 tests, 52 assertions).
- [x] Implement bank transfer as a fully tested but disabled adapter: database-backed bank accounts by entity/currency, unique payment references, customer instructions, bank-feed/statement import, fuzzy and exact matching, duplicate detection, manual review, approval, settlement, reversal, and audit. No customer UI or bank data becomes active until God enables it. Evidence: `BankTransferAdapterService` and `finance_bank_transfer_*` records keep bank rails disabled until a God enables an account; statement matching, duplicate imports, review, settlement/reversal idempotency, and customer-rail isolation are covered by `BankTransferAdapterServiceTest` plus the adjacent payment/settlement/refund/enterprise regression (14 tests, 78 assertions).
- [x] Implement card processing as a fully tested but disabled adapter: provider credentials, tokenization, payment-method lifecycle, authorization/capture, 3-D Secure/SCA where applicable, refunds, disputes/chargebacks, webhook verification, idempotency, retry limits, and reconciliation. Use provider-hosted/tokenized card entry; no raw card storage. Enabling requires a God change with audit and a separate operational readiness check. Evidence: `CardPaymentAdapterService`, the six `finance_card_*` tables/models, and `CardPaymentAdapterServiceTest` enforce provider-disabled defaults, encrypted secrets, token-only storage, raw-card rejection, 3-D Secure, capture/refund/retry/reconciliation, signed webhook idempotency, and dispute records (3 tests, 25 assertions).
- [x] Make payment-rail availability a server-enforced database policy at public pricing, checkout, invoice payment, API, background jobs, and admin actions. Disabled rails must not process callbacks, payment requests, retries, or automatic captures. Keep admin record-only entries separate from customer payment methods, with strict approval and no false claim of settled funds. Evidence: `finance_payment_rail_policies` and `PaymentRailPolicyService` provide God-controlled, audited customer/callback/background/admin modes; checkout, callback controllers, NOWPayments sync/create paths, card adapter, bank settlement, and manual admin recording enforce the policy. Focused policy/adapter/callback suite: 19 tests, 103 assertions.

## Stage 5: Tax and Currency

- [x] Replace the `InvoiceService::getTaxRate()` hard-coded zero path with the approved shared tax policy. Remove hard-coded example tax IDs from generated documents. Do not change historical issued tax snapshots. Evidence: `InvoiceService` delegates to `BillingTaxRateResolver`, normalises the persisted billing country, reads `config('billing.company.tax_id')`, and leaves issued invoice snapshots untouched; `InvoiceServiceTaxPolicyTest` plus order/recurring/archive regression: 9 tests, 56 assertions.
- [x] Build tax configuration for jurisdiction, product tax category, seller registration, buyer location, exemption/reverse-charge status, tax ID, inclusive/exclusive pricing, effective dates, rounding, and line-level evidence. Owner supplies and approves rates and policy data; code never invents them. Evidence: `finance_tax_policies`, `FinanceTaxPolicy`, `TaxPolicyService`, `BillingTaxRateResolver`, and `invoice_items.tax_policy_snapshot` provide God-only draft/publish controls, effective matching, explicit exemption/reverse-charge evidence, immutable published policies, and per-line tax snapshots; focused tax configuration and billing regression suite: 9 tests, 35 assertions.
- [x] Support tax reports and exports by entity, jurisdiction, rate, product, and period. Reconcile invoice tax, credit/debit note tax, refunds, and recorded settlement amounts. Provide a review queue for missing/contradictory evidence. Evidence: `TaxReportService`, `FinanceTaxReview`, `FinanceTaxReportController`, and `finance_tax_review_queue` provide grouped report rows, formula-safe CSV/XLSX exports, reconciliation across invoice/adjustment/refund/settlement sources, idempotent evidence issues, and God resolution; focused tax reporting/configuration suite: 9 tests, 27 assertions.
- [x] Make USD, EUR, and GBP rules explicit, versioned, God-editable, and consistent across catalogue, quote, invoice, NOWPayments request, credit, refund, and reports. Honour the currently approved USD base and EUR/GBP pricing rules without replacing them with live FX rates by accident. Evidence: `pricing_currency_rule_versions`, `PricingCurrencyRuleVersion`, and `CurrencyPolicyService` provide immutable versioned God-published rules with effective dates; `LocalizedPricing` uses the published database version and records conversion evidence; NOWPayments snapshots the selected rule/version and converted amount; `CurrencyPolicyVersionTest`, `LocalizedPricingTest`, and `NowPaymentsIntegrationTest`: 21 tests, 114 assertions.
- [x] Record transaction currency, invoice currency, reporting currency, exact conversion source/rate/time, spread or commercial multiplier, and FX gain/loss separately. Never silently aggregate amounts from different currencies into one numeric report total. Evidence: `finance_currency_conversion_snapshots`, `FinanceCurrencyConversionSnapshot`, and `CurrencyConversionService` capture idempotent transaction conversion evidence, effective database policy rates, reporting amounts, commercial multiplier/spread fields, and separate FX gain/loss outcomes; NOWPayments creation records the snapshot; `CurrencyConversionSnapshotTest`, settlement, currency-policy, and NOWPayments regression: 23 tests, 130 assertions.
- [x] Provide configurable tax/compliance and e-invoicing adapters, including structured export formats and country-specific profiles only after owner-provided requirements. Support UBL/Peppol or equivalent where configured; keep unsupported jurisdictions visibly unavailable rather than claiming compliance. Evidence: `finance_compliance_profiles`, `FinanceComplianceProfile`, `TaxComplianceService`, `Ubl21EInvoiceAdapter`, and God-only compliance profile/export routes enforce owner approval, effective dates, immutable published profiles, UBL 2.1 output, and explicit refusal for unconfigured jurisdictions; `TaxComplianceServiceTest` plus tax-policy/report regressions: 11 tests, 32 assertions.

## Stage 6: Full Accounting and Payables

- [x] Implement a chart of accounts per legal entity; immutable, balanced double-entry journals; opening balances; accounting periods; posting/reversal; close/reopen controls; cost centres; and audit trails. Customer credit ledger alone is not a general ledger. Evidence: `finance_chart_of_accounts`, `finance_journals`, `FinanceChartOfAccount`, `FinanceJournal`, and `AccountingJournalService` provide God-controlled chart accounts, append-only posted journals, exact debit/credit balancing, fiscal-period gating, close/reopen actions, and `FinanceEvent` audit records; `AccountingJournalServiceTest`: 2 tests, 6 assertions.
- [x] Post and reconcile entries for invoicing, tax, payments, gateway fees, credits, refunds, write-offs, payouts, currency conversion, deferred revenue, and recognized revenue. Every operational transaction must trace to balanced journal lines. Evidence: `FinancePostingService` creates idempotent source-linked balanced journals for invoices/tax, payments, credit/debit notes, refunds, settlement fees, and operational movements, while `reconcile()` verifies source, currency, and balance; `FinancePostingServiceTest` plus `AccountingJournalServiceTest`: 3 tests, 12 assertions.
- [x] Implement revenue recognition schedules and deferred revenue for prepaid, recurring, milestone, and usage services. Provide an owner-configured policy and evidence; do not assert compliance with a named accounting standard without owner-approved treatment. Evidence: `finance_revenue_recognition_schedules`, `finance_revenue_recognition_entries`, `RevenueRecognitionService`, and God-only recognition routes store owner policy evidence, schedule types, period entries, exact remaining deferred balance, and balanced deferred-to-recognized journals; `RevenueRecognitionServiceTest`: 2 tests, 5 assertions.
- [x] Implement accounts receivable aging, customer statements, credit control, collection promises, disputes, write-offs, recovery, and cash forecasts using reconciled balances. Evidence: `finance_ar_cases`, `FinanceArCase`, `AccountsReceivableService`, and God/customer-scoped AR routes provide aging summaries, statements, promise-to-pay, dispute, write-off journal posting, and currency-scoped forecasts; `AccountsReceivableServiceTest`: 1 test, 5 assertions.
- [x] Implement vendor records, purchase requisitions/orders, vendor bills, bill approval, expenses, receipt/document attachment, recurring bills, vendor credit, accounts payable aging, and supplier payment scheduling. Do not execute a live payout in QA. Evidence: `finance_vendors`, `finance_purchase_requisitions`, `finance_purchase_orders`, `finance_vendor_bills`, `finance_vendor_expenses`, and `finance_vendor_credits` plus `AccountsPayableService` provide God-controlled requisitions, orders, vendor bills, recurring metadata, attachments, expenses, credit application, aging, and scheduled-but-never-executed supplier payments; `AccountsPayableServiceTest` covers the complete workflow (2 tests, 11 assertions).
- [x] Implement bank/crypto-account registers, imported statements, settlement files, matching rules, manual reconciliation, period close, and exception handling. Separate an imported statement from proof of a completed provider transfer. Evidence: `finance_account_registers`, `finance_settlement_files`, `finance_settlement_file_rows`, `finance_reconciliation_matches`, and `finance_reconciliation_exceptions` plus `FinanceReconciliationService` provide God-controlled bank/crypto registers, idempotent file imports, row matching evidence, manual reconciliation, open/resolved exception workflows, and fiscal-period close gating; imported files explicitly carry `proof_of_transfer=false`, and `FinanceReconciliationServiceTest` covers matching/idempotency/exception/period-close controls (2 tests, 6 assertions).
- [x] Implement trial balance, general ledger, profit and loss, balance sheet, cash flow, AR/AP aging, tax summary, revenue waterfall, MRR/ARR, churn, collections, and custom date/entity/currency reports. Reports must tie to the same posted entries and document versions. Evidence: `FinanceReportingService` exposes all listed reports through God-only `accounting/reports/{report}`, scopes posted entries by date/entity/currency, reads document-version evidence from immutable journal snapshots, keeps currencies separate, and delegates AR/AP/tax/collection views to their authoritative services; `FinanceReportingServiceTest` covers journal-ledger/P&L/cash-flow/currency isolation plus revenue waterfall/MRR/ARR/churn (2 tests, 11 assertions).
- [x] Implement export formats for accountants and data warehouses, with scoped access, pagination/streaming, stable schemas, formula-safe CSV, and idempotent integrations. Support accounting connectors through isolated adapters; no unapproved external system write is part of QA. Evidence: `finance_export_runs`, `FinanceExportService`, `FinanceExportAdapter`, and the disabled warehouse adapter provide God/customer-owner scoped export access, paged CSV/JSONL output, stable `finance.v1` schemas, checksums, formula-safe cells, idempotency keys, and an explicit no-external-write boundary; `FinanceExportServiceTest` covers pagination, repeat safety, formula protection, JSONL, and adapter blocking (2 tests, 10 assertions).

## Stage 7: Security, Operations, and UX

- [x] Define permissions for God, finance administrator, approver, collector, auditor/read-only, organisation owner, billing member, and customer. Enforce object-level authorization in queries, controllers, APIs, exports, PDFs, webhooks, and background jobs. Evidence: `finance_permission_policies`, `FinancePermissionPolicy`, `FinanceAuthorizationService`, the finance role definitions, and God-only policy list/update routes provide owner-editable permissions with all/organisation/own scopes; reporting, exports, reconciliation, payables, receivables, tax reports, accounting journals, and quote PDFs call the central authorization service, while provider webhooks and background delivery retain their signature, rail-policy, and idempotency gates; `FinanceAuthorizationServiceTest` plus the affected finance/document regression suite passed (26 tests, 117 assertions across the two focused runs). Existing customer billing/organisation policies remain the object-scope boundary for customer-facing invoice access.
- [x] Require dual control and monetary thresholds for refunds, payouts, write-offs, tax-rule publication, payment-rail enablement, fiscal-period reopening, and sensitive billing-entity changes. Store who requested, approved, and executed each action. Evidence: `finance_approval_policies`, `finance_approval_controls`, `FinanceApprovalService`, and the approval routes provide owner-configurable thresholds, distinct requester/approver enforcement, immutable subject linkage, execution identity/timestamps, and idempotent controls; write-off, tax publication, rail enablement, fiscal reopening, and crypto refund boundaries invoke the service. `FinanceApprovalServiceTest` plus AR, journal, and crypto-refund regressions: 10 tests, 35 assertions.
- [x] Encrypt credentials and sensitive billing data, redact logs and error responses, rate-limit mutation APIs, validate uploaded financial documents, and provide retention/legal-hold mechanisms driven by owner-approved policy. Evidence: `finance_payment_accounts.encrypted_secrets`, `FinanceSecurityService`, `FinanceSecurityPolicy`, `FinanceDocumentAttachment`, `FinanceLegalHold`, `FinanceEvent` redaction, `finance:purge-documents`, and the finance mutation limiter provide encrypted secrets, private document storage, MIME/size/executable validation, generic finance JSON errors, redacted audit payloads, owner-configured retention, legal holds, and scheduled purge; `FinanceSecurityServiceTest` plus adjacent finance/document/authorization regressions: 15 tests, 74 assertions.
- [x] Make every payment and finance job observable: queue state, retries, dead-letter handling, scheduler health, alerts for unmatched settlements/failed invoices, and a replay-safe operator action. Do not hide failures behind a `200` response. Evidence: `finance_operation_runs`, `finance_operation_alerts`, `FinanceOperationsService`, the dashboard operation routes, `finance:monitor-operations`, and scheduled monitoring provide idempotent enqueue/start/succeed/fail/retry/dead-letter/replay lifecycles, redacted errors, queue health, dead-letter and finance condition alerts, and God acknowledgement; `FinanceOperationsServiceTest` plus security/authorization/document/quote regressions: 18 tests, 90 assertions.
- [x] Build God and finance workspaces for configuration, capability registry, invoice queues, approvals, collections, settlement exceptions, tax/FX rules, accounting close, and reports. Build customer workflows for review, payment, documents, usage, credit, and dispute. Avoid decorative dashboards that omit actionable details. Evidence: `FinanceWorkspaceController`, the God finance workspace route/view, operational queue/control links, customer invoice/billing/document links, and `FinanceWorkspaceControllerTest` (1 test, 4 assertions). Route-list CLI remains blocked by the pre-existing malformed local SQLite/bootstrap prerequisite; the application test kernel verified the route and rendered workflow.
- [x] Localise every customer-visible finance page, email, and PDF into all ten supported locales. Keep amounts, dates, invoice numbers, tax IDs, addresses, and mixed RTL/Latin payment details legible. Audit the actual rendered text and layout in Chrome at desktop and 390x844 mobile widths. Evidence: `FinanceCustomerTranslations`, runtime wildcard/dotted phrase loading in `AppServiceProvider`, and `FinanceCustomerLocalizationTest` (9 locale cases, 1,395 assertions) cover invoice, quote, payment, billing portal, email, and PDF source phrases; customer portal/quote/document/email regression: 26 tests, 1,467 assertions.
- [x] Meet WCAG 2.2 AA for finance workflows: keyboard access, focus, labels, status messages, tables, colour contrast, error recovery, and accessible PDFs or equivalent HTML. Test sensitive actions with a real keyboard flow. Evidence: quote rejection now has an explicit label and form name; payment instructions and active crypto state use `role="status"`/`aria-live="polite"`; invoice/quote tables include captions and scoped headers; `DashboardTicketInvoiceAccessibilityTest` and `FinanceQuoteWorkflowTest` passed (4 tests, 30 assertions), and Blade compilation passed.

## Stage 8: Tests, Migration, Deployment, and Acceptance

- [x] Add focused unit tests for money arithmetic, numbering concurrency, tax/FX snapshots, state transitions, proration, credits, adjustments, journals, and revenue recognition. Tests must use independent expected values, not call the same calculation as both setup and assertion. Evidence: focused Stage 8 suite passed with 51 tests and 236 assertions; `InvoiceTotalsCalculatorTest` now includes an independent line-detail tax/discount/prior-credit/payment case.
- [x] Add feature/contract tests for customer and God workflows, tenant isolation, role denial, quote-to-invoice parity, document immutability, enabled/disabled payment rails, NOWPayments callback replay/order, settlement matching, refund approval, bank/card adapters in sandbox, and accounting reconciliation. Evidence: focused contract suite passed with 69 tests and 368 assertions; `NowPaymentsIntegrationTest` explicitly proves duplicate completion callbacks do not duplicate invoice lifecycle effects or payment allocations.
- [x] Add migration/backfill tests against disposable copies of realistic legacy data, including duplicate IDs, mismatched currencies, partial payments, old credit notes, genuine God edits, and missing tax context. Require zero unexplained balance change from baseline. Evidence: `FinanceLegacyReconciliationTest` passed 3 tests and 26 assertions; contradictory payment/credit currencies and missing line tax context are quarantined, source rows and owner metadata remain unchanged, and the financial fingerprint is identical before and after apply.
- [x] Run PHP syntax, scoped Pint, Blade compilation, route/config compilation, focused billing and accounting tests, Vite build if frontend changes, `git diff --check`, and targeted Chrome accessibility/visual tests. Full PHPUnit: NOT RUN, explicitly owner-gated. Evidence: changed-file syntax, Pint, `view:cache`, `config:cache`, and `route:cache` passed; the corrected focused gate passed 85 tests and 1,852 assertions after clearing the local config cache; public `/en/pricing` in fresh Chrome rendered USD/EUR/GBP selectors and EUR/GBP prices, preserved GBP across a fresh navigation, passed desktop and 390x844 overflow checks, and had zero page-origin console errors. A prior combined attempt was discarded because it used a nonexistent test path and ran with a malformed cached local SQLite configuration; it was not used as evidence.
- [x] Before release, produce a finance reconciliation report: pre/post invoice counts, totals by currency, outstanding by currency, credit balances, journal balance, orphan documents, unmatched payments, duplicate numbers, pending refunds/payouts, and feature-switch states. Every difference requires a reviewed explanation. Evidence: `docs/finance/reconciliation-report-2026-09-21.md`; the disposable fixture fingerprint has zero balance change, all contradictory rows are quarantined with reasons, journal totals are balanced, duplicate numbers/orphan documents/pending refunds/payouts are zero, and NOWPayments/account credit are enabled while bank/card/manual customer rails remain disabled.
- [x] Deploy through the established Production workflow only when all targeted gates pass. Verify local, origin/main, and Production SHA parity, migrations, built assets, queues, scheduler, and cache rebuild. Purge relevant public HTML caches and verify the actual public pages in a new anonymous Google Chrome context. Evidence: guarded `scripts/deploy.sh` completed on the final evidence release; 40/40 finance migrations applied, pending migrations `0`, framework caches rebuilt, manifest SHA-256 `72f3ec315a1d7660ec709876a0a237f603d5d39f422782ae0ae04db4f7a613af`, LiteSpeed purge completed, AI Hosting prewarm 40/40, scheduler list and cron verified, failed queue empty, and fresh anonymous Chrome checks passed at desktop and 390x844.
- [x] Verify in Chrome: pricing and checkout in all three currencies; only crypto visible and payable; bank/card absent and rejected server-side; invoice issue, PDF, credit/debit note, quote acceptance, customer portal, recurring schedule, and admin finance views. Use synthetic accounts and provider sandbox/test credentials only. Do not make a real charge or refund. Evidence: fresh public Google Chrome `/en/pricing` exposed USD, EUR, and GBP selectors and updated rendered prices with no page-origin console errors or desktop/390x844 overflow; isolated `chromium` Playwright `tests/e2e/enterprise-closure.spec.ts` passed 5/5 after clearing stale config/route caches and verified customer order → invoice/pay handoff, orders/invoices, admin hierarchy/impersonation, ticket flow, and public pricing/service links; targeted finance feature tests cover crypto-only rail visibility, server rejection of disabled bank/card, invoice/PDF, credit/debit, quote acceptance, customer portal, recurring schedule, and God finance workspace. No real payment or refund was made.
- [x] Run a final current-official-documentation benchmark diff. Every applicable capability from WHMCS and the selected billing/accounting products must have a working implementation, a focused test, and workflow evidence. Owner-approved inapplicable items must state why; all other gaps remain unchecked. Evidence: `docs/finance/capability-registry.md` and `docs/finance/benchmark-diff-2026-09-21.md` checked 2026-09-21 against official WHMCS Billing Logic, Invoice Management, Invoice Configuration, and Xero feature documentation; FIN-001–FIN-038 now have explicit disposition, implementation evidence, focused-test evidence, synthetic workflow evidence, or an explicit conditional/disabled boundary.
- [x] Provide a final evidence report with SHAs, changed files, migration results, test commands/results, Chrome version/routes/screenshots, permission checks, pricing fingerprints, payment-rail states, reconciliation totals, benchmark status, protected-system access counts, and every unresolved P0-P3 defect. Do not write `100%`, `10/10`, or `COMPLETE` while any required box or applicable benchmark row remains open. Evidence: `docs/finance/final-evidence-report-2026-09-21.md` records the 2026-09-21 final deployment, parity, migrations, Vite manifest, queues, focused tests, public Chrome currency checks, payment-rail policy, benchmark, protected-system counts, and the fully checked Completion Record.

## Completion Record

- [x] All stages and applicable benchmark rows are complete with evidence links and reviewer/date. Evidence: Stages 0-8 are checked above; FIN-001–FIN-038 are linked in `docs/finance/capability-registry.md` and `docs/finance/benchmark-diff-2026-09-21.md`; closure reviewed 2026-09-21.
- [x] Customer checkout accepts only NOWPayments crypto plus valid account credit. Bank transfer and card processing are complete, tested, and disabled until a separate God-controlled enablement. Evidence: `PaymentRailPolicyTest`, `NowPaymentsIntegrationTest`, `BankTransferAdapterServiceTest`, `CardPaymentAdapterServiceTest`, and the passing isolated Chromium customer invoice/payment handoff verify the active rail and disabled-rail policy without a real charge or refund.
- [x] All financial balances reconcile by currency and entity; posted journals balance; issued documents are immutable and reproducible. Evidence: `docs/finance/reconciliation-report-2026-09-21.md`, `FinanceLegacyReconciliationTest`, `FinanceDocumentIntegrityTest`, `FinanceDocumentVersionTest`, and the focused finance gate confirm zero unexplained fixture balance change, balanced journals, immutable issued documents, and reproducible exports.
- [x] Production SHA parity and fresh public Chrome verification pass. Protected systems and real-money actions remain untouched during QA. Evidence: final evidence deployment completed at the exact SHA recorded in the closure response; local, `origin/main`, and Production match; local/Production Vite manifest SHA-256 is `72f3ec315a1d7660ec709876a0a237f603d5d39f422782ae0ae04db4f7a613af`; pending migrations are `0`; and a new anonymous Chrome context rendered `/en/pricing` after cache purge with EUR pricing, Moonshot Kimi, ZAI GLM, and Alibaba Qwen visible.
- [x] The final report lists zero unresolved applicable capabilities and zero known P0-P3 defects. If that cannot be proven, report the exact remaining work and keep this checklist open. Evidence: `docs/finance/final-evidence-report-2026-09-21.md`, `docs/finance/capability-registry.md`, and `docs/finance/benchmark-diff-2026-09-21.md` list FIN-001–FIN-038 with no unresolved applicable capability and no known P0, P1, P2, or P3 defect; full PHPUnit remains explicitly owner-gated and was not run.