14. Package Scenario QA Matrix

14.1 Purpose and scope

A focused QA pass re-verifying all four Shumoul packages end-to-end — pricing visibility, DB-level entitlement linkage, the full signup/onboarding journey, Starter Kit Preview, and runtime limit enforcement (including confirming no leakage of Starter's limits into POS/Finance tenants) — using brand-new dev tenants distinct from every prior verification pass. This is a QA/verification task: no feature was built, and no bug was found requiring a fix.

14.2 QA Matrix

Check	Shumoul Starter	Shumoul POS	Shumoul Finance Starter	Shumoul Finance Advanced
Pricing API visibility	Pass	Pass	Pass	Pass
Registration	Pass	Pass	Pass	Pass
Activation	Pass	Pass	Pass	Pass
Login	Pass	Pass	Pass	Pass
Onboarding status	Pass	Pass	Pass	Pass
Survey fetch	Pass (via status/answers roundtrip)	Pass	Pass	Pass
Survey submit	Pass	Pass	Pass	Pass
Recommendation	Pass	Pass	Pass	Pass
Settings filtering	Pass — exact expected group set	Pass — exact expected group set	Pass — exact expected group set	Pass — exact expected group set
Report entitlement	Pass — 9 reports (DB+seed cross-checked)	Pass — 11 reports	Pass — 8 reports	Pass — 14 reports
StarterKit Preview	Pass — Product chain entitled, Accounting Blocked	Pass — Product chain entitled, Accounting Blocked	Pass — Accounting chain entitled, Product Skipped (no entitlement)	Pass — Accounting chain entitled, Product Skipped (no entitlement)
Runtime limits	Pass — 2nd branch blocked (live)	Pass — 2nd branch AND 2nd user both allowed (live) — confirms no Starter-limit leakage	Pass — 2nd branch allowed (live) — confirms no leakage	Not tested live (heavy re-setup); structurally guaranteed identical to Finance Starter — same zero-rule-row seed data, same package-scoped resolution, already unit-tested generically
Dashboard readiness	Pass	Pass	Pass	Pass
No platform-admin leakage	Pass	Pass	Pass	Pass

14.3 Dev tenants used (this QA pass — distinct from all prior verification tenants)

Package	Tenant Id	Admin email	Org name (FName)
Shumoul Starter	950777	mohamed.alqlisi+qa-starter@gmail.com	Starter QA Store 2
Shumoul POS	481716	mohamed.alqlisi+qa-pos@gmail.com	POS QA Store 2
Shumoul Finance Starter	419352	mohamed.alqlisi+qa-finance-starter@gmail.com	Finance Starter QA Company 2
Shumoul Finance Advanced	163413	mohamed.alqlisi+qa-finance-advanced@gmail.com	Finance Advanced QA Company 2

Naming note: the task's originally suggested Arabic organization names (e.g. "متجر البداية التجريبي") collided with tenants already registered during the earlier package-blueprint verification pass — RegisterNewTenantRequestValidator enforces organization-name uniqueness. A distinguishing " 2" suffix was appended to each name (Arabic and English) to allow fresh, independent QA tenants without touching the prior ones. This is a naming-collision workaround only, not a product/business decision — no seed data or validation logic was changed.

14.4 Pricing API confirmation

GET api/Subscription/Packages/pricing, all 8 rows (4 packages × Monthly/Annually) confirmed present with the exact documented prices and distinct SubscriptionPlanPackage.Id values (see Chapter 5) — identical to the values already used successfully to register the tenants in §14.3, re-confirming both visibility and registerability in one pass.

14.5 DB-level entitlement verification (direct SQL against the dev Saas database)

Check	Result
Duplicate SubscriptionPackage rows	None found
Duplicate SubscriptionPackageFeature links	None found
Duplicate SubscriptionPackageFeatureRule rows	None found
Package → Feature links	Exactly the documented set for all 4 packages, MappingType = WithIn, all active
Package → Settings Group resolution	Starter: CashierAppsSettings, DiscountSettings, ProductSettings, SalesmanSettings, TaxSettings (5) · POS: same 6 incl. NotificationSettings · Finance Starter: CostCenterSettings, FinancialSettings, TaxSettings (3) · Finance Advanced: same 4 incl. ProjectSettings — exact match to Chapter 5
Package → Report resolution (total distinct reports)	Starter=9, POS=11, Finance Starter=8, Finance Advanced=14 — exact match, cross-checked independently against the embedded seed JSON via a new automated test (§14.8)
SubscriptionPackageFeatureRule rows	Exist only for Shumoul Starter (5 rows: Users/Branches/Devices/Products/SalesInvoices) — zero rows for any other package, confirmed by direct query
Platform/root-admin report or permission leakage	None found — no Permission.AdministrativeReports.* (or any TenancyPermissions-flavored) entry linked to any of the four packages

14.6 Signup journey and onboarding recommendation (live, all 4 packages)

All four tenants: registered → activated (dev-safe token read from DB) → logged in (each required 1-2 minutes of tenant-DB provisioning, surfaced as the expected 423 tenant_provisioning_in_progress before succeeding) → onboarding survey answered → recommendation generated. Settings-group filtering matched the documented expectation exactly and identically to the earlier verification pass on different tenants, confirming stability:

Package	Resolved settings-group patch
Shumoul Starter	CashierAppsSettings, DiscountSettings, ProductSettings, TaxSettings
Shumoul POS	CashierAppsSettings, DiscountSettings, NotificationSettings, ProductSettings, TaxSettings
Shumoul Finance Starter	CostCenterSettings, FinancialSettings, TaxSettings
Shumoul Finance Advanced	CostCenterSettings, FinancialSettings, ProjectSettings, TaxSettings

Dashboard readiness (authenticated login succeeds, tenant active/verified, no blocking first-login condition — see the Tenant Signup guide, §9.4) was satisfied for all four without needing to run onboarding/apply (the apply bridge is disabled by default in this environment, as already documented — re-enabling it was judged unnecessary for this QA pass since dashboard readiness does not depend on it).

14.7 StarterKit Preview (root-admin, read-only — Apply never run)

Re-confirms, on four brand-new tenants, the exact entitlement-gating design already documented in Chapter 10:

Package	Accounting chain	Product chain
Shumoul Starter	Blocked — no Features.AccountManagement	Failed (apply bridge disabled — not Blocked, confirming Features.ProductsManagement is entitled)
Shumoul POS	Blocked — no Features.AccountManagement	Failed (same bridge-disabled reason — entitled)
Shumoul Finance Starter	Failed (apply bridge disabled — not Blocked, confirming Features.AccountManagement is entitled)	Skipped — explicitly cites missing Features.ProductsManagement
Shumoul Finance Advanced	Failed (same — entitled)	Skipped — missing entitlement

CostCenters was Skipped for the POS-like packages (onboarding answer said not needed) and skipped as a downstream consequence of the bridge-disabled accounting step for the finance packages — identical pattern to the prior verification pass, confirming the needsCostCenters answer/entitlement interaction is stable across independent tenants.

14.8 Runtime limit verification — confirming no leakage (live + new tests)

Live, this QA pass:

• Shumoul Starter (950777): second branch creation → 422, "Package limit exceeded: maximum 1 Branches."
• Shumoul POS (481716): second branch creation → 200 (succeeded); second user creation → 200 (succeeded) — directly confirms POS does not inherit Starter's Branch/User limits.
• Shumoul Finance Starter (419352): second branch creation → 200 (succeeded) — directly confirms Finance Starter does not inherit Starter/POS limits either.
• Shumoul Finance Advanced: not live-tested this pass (would require the same fresh location/branch lookups repeated a fourth time) — structurally identical guarantee applies (zero SubscriptionPackageFeatureRule rows exist for this package, per §14.5's direct DB query), and is covered generically by the automated tests below.

New automated tests (Shumoul.Framework.MultiTenancy.Test.Packages.ShumoulPackageCapabilityMatrixShould, 7 tests, all passing):

• Exact total report count per package (9/11/8/14), cross-checked against the live DB query in §14.5.
• POS's report set is always a strict superset of Starter's, never smaller or disjoint.
• SubscriptionPackageFeatureRule rows exist only for Shumoul Starter — the direct, seed-level reason no other package can ever inherit a limit.
• Every one of the four packages has at least one active feature link (guards against an empty/broken package going unnoticed).

Combined with the pre-existing tests from the package-limit-enforcement phase (package-scoped rule resolution, same-feature-different-package non-leak scenarios, exact Starter boundary tests), limit non-leakage for all three non-Starter packages is now covered by both live verification (2 of 3) and automated tests (all 3, plus the general mechanism).

14.9 Security re-confirmation

No platform/root-admin permission or report was found linked to any of the four packages (§14.5) — this was already structurally guaranteed (see Chapter 6) and is re-confirmed here with fresh data. No MenuClaims, PermissionConstants, or TenancyPermissions value was touched by this QA pass.

14.10 Known gaps / not tested

• Shumoul Finance Advanced's runtime non-leakage was not independently live-tested this pass (time/setup cost of a fourth full location-lookup-and-create cycle) — covered instead by the direct DB query (zero rule rows for this package) and the generic automated tests.
• Products (#6 blocked) and Sales Invoices (#11 blocked) were not re-exercised live in this QA pass — already thoroughly live/unit-tested in the package-limit-enforcement phase; re-running them here would require the same heavy reference-data setup (BusinessType/Department/Category/UnitOfMeasure for Products; full POS/tax/customer setup for 10 real invoices) with no new information gained.
• POS/Finance device-limit non-leakage was not live-tested (Starter's own Device limit was already found to be pre-consumed by earlier session testing, per the prior phase's report) — covered by the same generic "zero rule rows for non-Starter packages" DB fact and automated test.
• onboarding/apply was not run for any of the four QA tenants (bridge disabled by default; not required to confirm dashboard readiness) — consistent with this task's own instruction not to run Apply unless necessary. Update: a later, separate task did run apply end-to-end with the bridge enabled (dev-only, on a different dev tenant) and confirmed it applies correctly, including subscription-entitlement filtering removing LoyaltySettings for a Shumoul Starter tenant exactly as expected — see Business Onboarding & Smart Configuration, Chapter 21.

14.11 Production deployment / verification notes

No source, schema, or seed data changed in this QA pass — only one new test file (MultiTenancyApi) and this documentation page. Nothing to deploy differently from what is already live in the target environment. If run against production (read-only) for a release sanity check, the same GET api/Subscription/Packages/pricing call and the same DB queries in §14.5 are safe, read-only checks.