Keep domain products under their owning application

Purpose

A domain application saves the Accounting product alongside its own extension record.

How It Works

A domain application saves the Accounting product alongside its own extension record. Its trusted database session establishes which application is acting. The owner check confines service callers to their own kinds. Console and system callers have a broader path because domain screens save the common record before the extension. Database saves can share the domain transaction, unlike the console’s separate requests. The database contract keeps omitted scalar values, whereas the API replacement clears them. Product-owned template composition also remains an API concern. A domain needs an executable rollback test before claiming its extension and the common product always fail together.

Relationships

This outcome uses understand the available product kinds.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: Shared product writes respect application ownership.
Surfaces: apijob
Intent sources: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D4services-accounting:docs/migrations/accounting-modernization/products-shared/README.md#D-1services-accounting:docs/migrations/accounting-modernization/products-shared/README.md#D-2

Controls

25 controls apply, from the corpus control catalogue.

TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-IAM-006 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-DAT-001 TC-DAT-004 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-005

Permissions

Key	Checked at	Scope
`accounting.products.create`	service	record
`accounting.products.update`	service	record
`accounting.products.delete`	service	record

Business Rules

12 rules, 10 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	Service callers may mutate only product kinds owned by their application, with refusals identifying the owner, kind and caller. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D4 proved by `ATS-ACC-PRD-001-06`, `ATS-ACC-PRD-007-01`, `TST-ACC-PRD-042`, `TST-ACC-PRD-066`	permission	service, database	test services-accounting:modules/products/tests/integration/services/persistence/products.shared-base.integration.spec.js#refuses Commerce creating a membership package, naming the owner, the type and the caller
`02`must prove Proposed	Domain service callers cannot mutate Accounting-owned product kinds. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#D4 proved by `ATS-ACC-PRD-007-01`, `TST-ACC-PRD-042`, `TST-ACC-PRD-066`	permission	service, database	test services-accounting:modules/products/tests/integration/services/persistence/products.shared-base.integration.spec.js#refuses a service creating an Accounting-owned type
`03`must prove Proposed	Console and system callers may write any active product kind, allowing the console to save the common product before its domain extension. origin: services-accounting:docs/migrations/accounting-modernization/products-shared/README.md#D-2 proved by `ATS-ACC-PRD-007-02`, `TST-ACC-PRD-029`, `TST-ACC-PRD-042`, `TST-ACC-PRD-066`	permission	service	test services-accounting:modules/products/tests/unit/rules/product-rules.spec.js#lets a console caller write any type (the console calls Accounting first and the domain second)
`04`must prove Proposed	A domain can save the common product within its own database transaction so the common record and extension share a commit boundary. origin: services-accounting:docs/migrations/accounting-modernization/products-shared/README.md#D-2 proved by `ATS-ACC-PRD-007-03`, `ATS-ACC-PRD-007-10`, `TST-ACC-PRD-032`	invariant	database	test services-accounting:modules/products/tests/integration/db/save-product-function.integration.spec.js#is the same product Accounting’s own persistence service reads
`05`must prove Proposed	Database product writes derive workspace, actor and application from session context and reject sessions lacking a workspace or application identity. proved by `ATS-ACC-PRD-007-04`, `TST-ACC-PRD-032`	permission	database	test services-accounting:modules/products/tests/integration/db/save-product-function.integration.spec.js#refuses a transaction with no tenant as RHP04
`06`must prove Proposed	The database saving path shares product validation sentences with Accounting and distinguishes invalid input, incompatible state, absence and unauthorized callers. proved by `ATS-ACC-PRD-007-05`, `TST-ACC-PRD-032`	invariant	database	test services-accounting:modules/products/tests/integration/db/save-product-function.integration.spec.js#refuses bundled prices above the product price with one sentence on both paths
`07`must prove Proposed	The database saving path requires a supplied identity, writes no accounting setup and rejects product-owned confirmation content. proved by `ATS-ACC-PRD-007-06`, `TST-ACC-PRD-032`	validation	database	test services-accounting:modules/products/tests/integration/db/save-product-function.integration.spec.js#refuses a product-specific confirmation e-mail, which Accounting’s API composes
`08`must prove Proposed	Database replacement preserves omitted scalar properties, clears explicit empty values and replaces collections in full. proved by `ATS-ACC-PRD-007-07`, `ATS-ACC-PRD-007-10`, `TST-ACC-PRD-032`	policy	database	test services-accounting:modules/products/tests/integration/db/save-product-function.integration.spec.js#replaces the row and every collection as a whole, keeping an omitted property and clearing a null one
`09` Proposed	The database path provides creation, replacement and retirement; console API reactivation and deletion currently expose no domain service route.	policy	database	documented services-accounting:docs/accounting/products.md#The domain write path
`10` Proposed	Accounting permits a domain product without an extension record and leaves completion or retirement to that domain.	policy	service	documented services-accounting:docs/accounting/products.md#Who may write a product (the owner rule)
`11`must prove Proposed	Database domain saving defaults an omitted component price to zero and compares unweighted component price sums with the bundle’s list prices. proved by `ATS-ACC-PRD-007-08`	calculation	database	observed services-accounting:db/migrations/20261019201047_product_lock_and_held_bundle_components.sql
`12`must prove Proposed	Database domain saving continues admitting audiences already held by the product when Commerce’s audience registry exists. proved by `ATS-ACC-PRD-007-09`	validation	database	observed services-accounting:db/migrations/20261019201047_product_lock_and_held_bundle_components.sql

Scenarios

Id	Given	When	Then	Provenance
`01`	Membership saves a package inside its own transaction.	The extension write fails after the common product save.	The documented workflow expects rollback of both records, pending executable cross-domain proof.	documented react-console:acceptance/accounting/journeys/products/ACT-ACC-0147.json
`02`	Commerce acts under its service identity.	It attempts to create a Membership package.	Ownership validation names Membership and rejects the write.	test services-accounting:modules/products/tests/integration/services/persistence/products.shared-base.integration.spec.js#refuses Commerce creating a membership package, naming the owner, the type and the caller

Planning

Implementation

Keep domain products under their owning application ​

Purpose ​

How It Works ​

Relationships ​