Frontier integration handoff — SimLOD 1.3#
The generic provider-command gate described by Frontier's M2 proposal is implemented in this SimLOD development line. The exact public contract is provider-commands.md. Frontier remains a separate project and must implement its own mission/economy semantics.
What Frontier can now use#
- Implement
ICommandSimulationProvideron its ownPawnSimulationProvider. - Return
ProviderCommandDecision.Accept(completePayload, result)orRefuse(reasonCode, detail). - Submit through
SimLODWorldComponent.SubmitCommand(entity, expectedRevision, requestKey, kind, arguments). - Resolve uncertainty through
GetCommandReceipt(entity, requestKey)and replay the original accepted key. - Account deterministic partial time through context.EffectiveTick without changing the fixed schedule/RNG.
- Use the existing native queued lifecycle/settlement independently. Commands cannot modify a pending plan.
This follows the Frontier proposal's main boundaries. Specific API choices to adapt to:
| Proposed concern | Implemented contract |
|---|---|
| Event boundary not ready | Refused plus provider-defined reason such as boundary-pending |
| Known entity, no accepted receipt | Receipt with Status == NotFound; not null |
| Corrupt archive/native journal | Throws through existing facade validation; do not interpret as NotFound |
| Provider callback failure | ProviderFailure with quarantine; no new accepted receipt |
| Replay identity | Exact entity/key/kind/arguments; expected revision excluded |
| Original format for a saved result | Receipt includes original Schema and ModelVersion |
| New commands on paused records | Refused as EntityUnavailable; existing accepted receipts remain readable |
| Capability marker | Public literal SimLOD.API.ProviderCommandContract.Version = 1, inspected by name before command-dependent types load; CLR version is unchanged |
Frontier's integration target is the staged 1.3 public DLL, not its pinned 1.2 input. The original local 1.2 package was not overwritten during development. Use the exact candidate/package location and hash from the SimLOD acceptance/release manifest, and rebuild Frontier against that public DLL with Private=false. No framework implementation reference or copied framework DLL should ship in Frontier.
Consumer release checklist owned by Frontier#
This list identifies Frontier's responsibilities; some are already in progress in that separate project. A source-hashed copy built against the final 1.3 DLL and passed its native continuity fixture with command support enabled. The actual pending, faulted and prepared command-lock assertions passed, proving the capability bootstrap loaded. See the integration audit. This is not acceptance of the full paid mission loop.
- Verify schema migration from its actual M1 checkpoint, command-aware mission state and startup capability checks.
- Complete and validate pure start/recall/extend/departure-complete/delivery-ack rules, including pending random-event boundaries.
- Complete native silver escrow and shipment ownership/recovery. An accepted command receipt does not itself prove a physical payment or cargo transfer.
- Connect ordinary UI, visitor/departure duties, deterministic reports and repeated missions.
- Test the combined paid gameplay loop and its failure matrix against the final SimLOD package.
The framework native fixture demonstrates a public command provider, stable and retained Pawn commands, receipt replay across native operations, provider absence/restoration and actual saves. It is not a playable Frontier mission or an economy test. Do not add its assertion totals to Frontier acceptance.
No further generic framework capability has been identified as a prerequisite for the bounded first Frontier release. Actual integration can still reveal bugs or a narrowly justified addition. Off-map injuries, multiple companies, arbitrary colonists, rescue maps and map virtualization remain separate future gates.