Complete end-to-end coverage through the existing live-server integration suite

Status reconciliation — 2026-10-22

Baseline implementation merged in PR #76. Keep this umbrella open as explicitly required by PAR-502; eight-profile results on the historical runtime do not certify Paper 26.3 or all remaining integrations. Continue through PAR-502 and the existing ADT-193 runtime owner.

Goal

Make Hibernia Economy's end-to-end coverage as complete as practical using the existing live-server tests. Prove the shipped player/admin journeys and cross-plugin behavior against a running stack, including rejection and failure paths. Measure completeness by behavioral coverage and demonstrated fault detection, not test counts or line coverage.

Starting point

Extend integration-tests/ and ops/integration/run.sh, rather than creating a parallel harness. The existing suite uses an MCProtocolLib mock player, RCON setup, real Paper plugins, MariaDB/Flyway, REST requests, and JDBC/chat assertions. Reuse Await, Barrier, Perms, ChestShopFixture and the existing ledger/inventory/API helpers.

PAR-354's CI/test-quality overhaul and main-branch enforcement are complete per the maintainer; this is a new completeness pass, not reopening that work. The checked-out README describes roughly 500 tests and Paper 1.21.11; establish the actual current baseline from develop. ADT-193 records staging on Paper 26.3, so reconcile server/client protocol compatibility explicitly.

Scope

1. Build a source-backed coverage matrix. Inventory implemented commands/subcommands, permissions/roles, REST endpoints, events, scheduled jobs, configuration branches, integrations and player/admin journeys. Map each to executable live tests and meaningful assertions. Identify missing, weak, disabled and stub-only coverage. Include recent merged features; do not assume an open ticket means missing code.
2. Treasury: joining/starting balances; personal/government accounts and access; pay/deposit/withdraw/admin adjustments/fines; ambiguous names and account types; ledger/history/balance consistency; taxes, exemptions, rounding and repeated triggers; insufficient funds, invalid amounts, unauthorized actions, concurrent transfers and idempotency.
3. Business: firm/account lifecycle, staff/roles/invites, deposits/withdrawals/payments, ownership transfer and access revocation, payroll/taxes, archived entities, cross-firm isolation, and applicable menus/chat integrations.
4. ChestShop/market: real placement/sign editing and buy/sell interactions; player, business and admin shops; actual inventory and money movement; tax/custom items; restrictions/protection; insufficient funds/stock/capacity; rollback without duplication or loss; concurrent purchases; registry discovery/resync, finder/previews and lifecycle cleanup.
5. TreasuryAPI/REST and connected integrations: token issuance/scopes/expiry/revocation, account authorization, both transfer engines, retries/idempotency, transaction feeds, webhooks/retries, LuckPerms reconciliation, Vault integrations and Realty money/access flows where present. Exercise deployed implementations, including cross-service read-after-write behavior.
6. Explorer journeys: connect the existing browser E2E suite to representative live-stack flows where feasible: perform an in-game/API action, verify persisted ledger state, then verify the correct account/history/market/tax presentation and authorized/unauthorized visibility. Browser rendering must be checked with a browser, not inferred from SQL assertions.
7. Lifecycle/recovery: reconnect and persistence, relevant configuration reloads, plugin/server restart and scheduled processing, plus controlled dependency failures where the harness supports them. Prioritize money integrity and access isolation.
8. Extend the mock client/fixtures where missing interaction or observation support prevents real journey coverage. Distinguish real-plugin acceptance from substitutes such as nexo-stub; explicitly record Java/Bedrock and licensed-plugin gaps rather than counting them as covered.

Test quality and execution

• Drive behavior through actual player packets, commands or HTTP/browser entry points. RCON/JDBC may prepare fixtures and inspect outcomes; they must not bypass the behavior under test.
• Assert exact balances, balanced ledger postings, inventory changes, ownership/access and relevant user-visible results. Rejections must prove the request was processed and no forbidden mutation occurred.
• Use positive barriers and bounded condition waits; no arbitrary sleeps, swallowed failures, unconditional retries or tests that pass without exercising the feature.
• Use isolated fixture identities/world areas and repeatable setup/cleanup. Default to the disposable live stack; do not reset a shared server/database or change production authentication to make tests run.
• Provide capability preflight for required plugins, protocol, credentials and services. Missing required capabilities fail the relevant acceptance profile; optional/manual checks remain explicitly reported gaps.
• Keep targeted runs practical and document the full acceptance command/profile. Preserve diagnostic artifacts (JUnit reports, server/API logs and relevant state evidence) without credentials.

Acceptance criteria

• A reviewed coverage matrix accounts for every discovered implemented feature/journey: automated and passing, or explicitly blocked/manual with reason and a linked follow-up. No silent skips or unsupported claim of 100% coverage.
• All identified critical money-moving and authorization journeys have real live-stack success, denial and relevant failure/concurrency coverage. Any unavailable critical integration remains a stated acceptance blocker.
• Newly added high-risk tests demonstrate fault detection with a controlled fault or temporary regression, then pass with correct behavior restored.
• The full applicable live suite passes twice consecutively from clean disposable state without retry masking; report duration, environment, commit, server/plugin versions and test/skip counts.
• Representative cross-plugin journeys and Explorer read-after-write flows pass against the same stack; real-plugin checks are distinguished from stub-backed tests.
• Update run documentation and produce a final coverage/gap report. Link actual defects found to focused tasks and keep this task open until its agreed automated scope passes.

Related: PAR-354 (completed foundation), ADT-193 (runtime compatibility), PAR-496 (ChestShop acceptance). This task is to extend and execute coverage, not merely write an audit report.