Manifest and dependencies

Declare identity, package provenance, compatibility, realms and a deterministic dependency graph.

Manifest fields

Create a Lithera RP Addon Manifest resource with the .lraddon extension. Its publish configuration includes code.

Field	Contract
`AddonId`	Stable normalized id. It must match the attribute, implementation and operator entry.
`DisplayName`, `Summary`, `Author`, `Website`	Operator-facing metadata.
`Version`	Valid addon version used by dependency constraints.
`ProtocolVersion`	Positive integer that must equal `ILitherarpAddon.ProtocolVersion`. Change it when host and client protocols are incompatible.
`Realm`	`Shared`, `Server` or `Client`. It controls which lifecycle callbacks run.
`FailurePolicy`	`Required` blocks a healthy activation plan on failure. `Optional` leaves that addon inactive and lets the valid plan continue.
`MinimumGameVersion`	Minimum LitheraRP version required by the manifest policy.
`RequiredPackages`	Additional package idents mounted as assets under the server package allowlist.
`DependsOn`	Required code addon ids and accepted version constraints.
`OptionalDependsOn`	Dependencies used for ordering when present. Absence does not invalidate this addon.
`ConflictsWith`	Addon ids that cannot share the active plan.
`RequestedCapabilities`	Sensitive capability ids requested by the creator. A request alone grants nothing.
`ConfigPatches`	Validated data patches. Code and patches can ship in the same manifest.

Dependencies and order

The planner rejects ambiguous ids, missing required dependencies, incompatible versions, conflicts and cycles. Dependencies always activate first. Unrelated addons use normalized id order, so host and clients receive the same plan.

Accepted constraints include exact versions, comparison chains, caret, tilde and wildcard forms such as 1.2.3, >=1.2.0 <2.0.0, ^1.2.0, ~1.2.3 and 1.*.

Package revisions

The host records the exact addon and required-package revisions in the public snapshot. A revision mismatch is a failure instead of a silent drift to different assets or code. Required package failures participate in readiness; optional package failures do not block a client.

The snapshot and addon fingerprints are deterministic consistency hashes over the resolved plan. They detect drift between host and client; they are not signatures and do not establish creator trust.

Capabilities

The effective set is the intersection of requestedCapabilities imported from the manifest and grantedCapabilities chosen by the operator. It is empty by default. Call context.HasCapability(id) before presenting a capability-dependent feature.

LitheraRP records the normalized package ident that received each operator grant. If packageIdent changes or the grant has no matching provenance, apply clears the stored grants instead of transferring them to different code.

The context receives an immutable capability snapshot before loading begins, so the same result is available from loading, loaded and ready callbacks. A changed operator grant causes reconciliation with a new context.

The current sensitive capability is admission.whitelist_override. It permits an authorized handler to allow a connection rejected only by the core whitelist. Server authorization and sanctions run before that stage and cannot be bypassed.

Publishing check

Publish the .lraddon from its Inspector. Do not rely on Batch Publish for a code revision.
In File Uploads, verify .bin/manifest.json and the expected .bin/<assembly>.cll.
Give operators the package ident, not a local filesystem path.