Mortezakoohjani 091b33a638 feat(platform): finalize commercial runtime, platform shell and hospitality production frontend

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-07-28 20:39:10 +03:30

4.0 KiB

Raw Blame History

Dynamic Product Registry

Contracts only. Unlimited future products via registry entries — no architecture edits required.
Catalog shapes: product-catalog.md
Contract version: product-registry.v1

1. Purpose

The Platform Product Registry is the authoritative, append-only logical registry of all PlatformProducts.

When a new commercial product is introduced, operators/agents add a registry entry (+ docs + optional capability/bundle mapping). Core commercial architecture remains unchanged.

2. Registry entry

Field	Type	Required	Meaning
`product_code`	string	yes	Unique open key
`display_name`	string	yes
`category_code`	string	yes	Open category
`capabilities[]`	`{ capability_code, role, required }`	yes	Refs only
`dependencies[]`	PlatformProductDependency	no
`visibility`	PlatformProductVisibility	yes
`commercial_status`	enum	yes	planned/preview/ga/deprecated/retired
`maturity`	enum	yes	concept→mature
`documentation_ref`	string	yes
`required_services[]`	string[]	no	Service identifiers
`optional_services[]`	string[]	no
`reserved_features[]`	string[]	no	Not yet implemented keys
`marketplace`	MarketplaceCompatibilityDeclaration	no	See §4
`version_code`	string	yes	Current version
`tags[]`	string[]	no
`future_product`	bool	no	Marks conceptual / not sellable yet
`ext`	object	no	Additive

Logical record:

PlatformProductRegistryEntry {
  product_code
  display_name
  category_code
  capabilities[]
  dependencies[]
  visibility
  commercial_status
  maturity
  documentation_ref
  required_services[]
  optional_services[]
  reserved_features[]
  marketplace?
  version_code
  tags[]
  future_product?
  ext?
}

3. Registry operations (logical)

Operation	Effect	Architecture change?
`register`	Insert new entry	No
`update_version`	Add PlatformProductVersion	No
`deprecate`	Set status + optional replacement	No
`retire`	Hide from sellable catalogs	No
`map_bundle`	Optional Business Bundle refs	No

There is no predefined limit on entry count.

4. Marketplace Compatibility Declaration

Marketplace is an independent PlatformProduct. Other products declare compatibility only:

Field	Type	Meaning
`stance`	enum	`requires_marketplace` \| `marketplace_optional` \| `marketplace_compatible` \| `none`
`roles[]`	enum[]	Open multi-select: `marketplace_publisher` \| `marketplace_consumer` \| `marketplace_plugin` \| `marketplace_extension` \| `marketplace_integration`
`marketplace_product_code`	string	Default `product.marketplace` (or future fork codes)
`notes`	string?

Rules

Marketplace owns marketplace domain data and engines (when implemented).
Declaring marketplace_plugin does not transfer ownership to Marketplace.
requires_marketplace blocks activation recommendations unless Marketplace is licensed (future evaluator).
Core commercial architecture never embeds Marketplace internals.

5. Future products

Entries with future_product: true or maturity: concept / commercial_status: planned:

Appear in admin registry
MAY appear in documentation matrices
MUST NOT imply implementation authorization
MAY reserve capability and feature codes

6. Extensibility guarantee

Architecture must never require modification when a new product is added. Only registry entries.

Validators of this contract FAIL if a change request proposes:

Hardcoding product enums in Core commercial aggregates
Forking commercial architecture per vertical
Embedding product implementations inside Business Bundles

4.0 KiB Raw Blame History