FOnline Public Contract Index

This page is the revision-pinned entry point to the reusable interfaces and data formats exposed by the FOnline engine. It is generated from the same machine-readable models used by contract-diff checks. A reachable symbol or accepted file is not automatically a compatibility promise; the stability label on its owning contract is authoritative.

Contract decision

Resolve every disagreement in this exact four-level order: (1) owning Engine source and its metadata define behavior and stability; (2) the same-revision machine model defines exact inventory and drives diffs; (3) the generated human reference provides navigation; (4) handwritten guides provide workflow and context but do not override the first three levels. Reachability alone is not a compatibility promise. This index does not define annotation spelling or an embedding project’s pin mechanism; do not invent either when the owning source or project does not supply it.

The native script API is a revision-pinned experimental inventory: the current validated inventory-pinned scope classifies the complete inventory, so do not require an individual tag on every symbol. If that scope is absent or fails validation, unannotated native symbols remain internal. Pin the exact Engine revision, but when the embedding project does not document pin storage, do not propose a dedicated file, CI variable, config field, FO_ENGINE_ROOT, FO_WORKSPACE, or another mechanism. On upgrade, record the exact commit, compare all generated contract domains, and follow the Engine Upgrade Guide before moving the pin.

Contract surfaces

The current revision contains 17 modeled contract domains: experimental 14, internal 3.

Native script API status

• Discovered symbols: 2555
• Symbols with source-backed descriptions: 2555
• Symbols without descriptions: 0
• Explicitly classified symbols: 2555
• Symbols inheriting the default internal classification: 0

The generated native reference is complete as an inventory of the modeled code-generation surface. Its current inventory-pinned scope is explicitly experimental and requires an exact Engine revision pin; it is not a broad stable compatibility promise. If the scope is absent or fails validation, unannotated native symbols remain internal.

Stability vocabulary

• stable: maintained compatibility contract; incompatible changes require the documented migration process.
• experimental: usable with an exact Engine revision pin; compatibility may change with documented migration notes.
• deprecated: retained temporarily for migration and scheduled for removal through the change-management process.
• internal: implementation detail with no downstream compatibility promise.

See ADR-0002 for classification rules and Contract Change Management for review, diff, deprecation, and migration requirements.

Source-of-truth order

1. The owning Engine source and its explicit contract metadata define behavior and stability.
2. The machine model records the extracted contract for the pinned revision and drives automated diffs.
3. The generated human reference explains the modeled surface and routes to focused manuals.
4. Handwritten guides provide workflows and examples but do not silently widen compatibility guarantees.

When these layers disagree, treat the claim as unverified, fix the source metadata or generator, regenerate the affected model and reference, and update migration guidance in the same change.

Project-owned boundaries

The Engine contract does not define a game’s remote-call schema, concrete prototypes, content identifiers, gameplay rules, deployment topology, service credentials, signing policy, or release acceptance matrix. Embedding projects must document and validate those boundaries in their own repositories. Engine manuals may use project evidence as non-normative context, but must remain usable without that project.

Revision pinning and upgrades

Pin the Engine by an exact commit in every game repository and public example. Before moving the pin, compare all generated contract domains, review breaking and behavioral changes, follow the Engine Upgrade Guide, and re-run the embedding project’s build, bake, test, packaging, and documentation checks. Platform qualification is tracked separately in the Support Matrix.