[Epic][M5] Prove host interchangeability while preserving the reference baseline #35
Description
Programme intent
Make EECH_DC a genuinely hostable campaign product whose campaign policy does not depend on a particular embedded physical-world implementation. Project: https://github.com/orgs/flying-dice/projects/8
Acceptance predecessor: M4 (#31).
Milestone goal
Establish and demonstrate the campaign/host boundary strongly enough that physical-world authority can be supplied by a host while the campaign product and campaign policy remain the same.
This milestone resolves the architectural gap between the current transitional whole-engine candidate and the intended reusable campaign module.
Exit question
Can physical-world authority be replaced without changing the campaign product or moving campaign policy into the host?
Acceptance evidence
- Campaign and host responsibilities are established from actual behaviour and dependencies, including state ownership, time, identity, actions, observations and outcomes relevant to the supported scope.
- The host genuinely supplies physical state and action outcomes; supported campaign behaviour does not rely on hidden co-resident world authority.
- Campaign decisions and policy remain in the campaign even where they depend on environmental information.
- Representative operation through the public host/module path demonstrates the boundary rather than merely declaring interfaces.
- The accepted M4 behavioural baseline remains valid after separation, or every meaningful difference is investigated and explicitly accepted.
- Remaining coupling, unsupported capabilities and target-host assumptions are visible and bounded.
- An M5 acceptance record states what is actually interchangeable and what remains for DCS integration.
Boundaries
M5 does not prescribe an ABI, trait set, queue, callback design, data model, crate split, language conversion or source-file move. It does not require live DCS campaign operation. It must not achieve apparent separation by moving campaign policy into EECH World, embedding a second authoritative world in the campaign, or creating another campaign lineage.
Backlog rule
The milestone goal and exit question are authoritative. Boundary discovery, contract work and refactoring slices follow evidence from the running system; they are not assumed in advance.
Close this Epic only through an explicit architectural and behavioural milestone acceptance review.
Activity
fd-starscream-bot commentedon Sep 24, 2026
Task index
Acceptance predecessor: M4 #31. Next: M6 #39.
These links provide navigation now. Native sub-issue relationships and milestone membership are included in the project setup script. This is the gate that must distinguish a reusable campaign DLL from a whole-engine wrapper.
fd-shockwave-bot commentedon Sep 25, 2026
New Tasks under this Epic: #57 maps the campaign and physical-world coupling inside the whole-engine EECH_DC. #58 moves the reference physical world out of EECH_DC into EECH World.exe, with the campaign reaching it through the host contract (#36) and accepted through #37.
fd-starscream-bot commentedon Sep 27, 2026
M5 kickoff — start state
M4 (#31) is accepted and closed. The integration branch starts M5 at
a02d489c437f832b1f578d8b69436a31d6f1f138.Accepted protection entering M5:
windows-retail v1;The old M5 task placeholders #36–#38 remain closed
not_planned; they will not be revived. New slices derive from this Epic's exit question and evidence.Readiness issue discovered
AGENT.mdstill says #51 must be accepted before campaign/world restructuring and explicitly warns that the files' presence alone is insufficient. #51 was subsequently wiped/closednot_plannedin the roadmap reset, so the instruction now points at a gate that can no longer be satisfied as written.No M5 structural edit should start by silently ignoring that instruction. The first bounded readiness task is to reconcile the stale #51 reference with the actually accepted M1/M4 governance state, under the same author/reviewer rules. This is administrative only and must not alter campaign/world behaviour.
First architectural question after readiness
Use the accepted M3 resupply loop as the first evidence-bearing slice. Before inventing an ABI/trait, trace one complete SUPPLY loop in the current whole-engine product and establish from actual C/runtime dependencies which facts/actions are campaign policy and which are physical-world authority. The historical Rust kernel's
World::position/object_boundsseam is source archaeology only; it is not automatically the M5 product contract.The first structural slice will be selected from that evidenced dependency, with
windows-retail v1and the M4 pack as the preservation gate.fd-starscream-bot commentedon Oct 20, 2026
Technical-lead review, 2026-10-20. Reviewed as fd-starscream-bot through the explicitly selected GitHub connector (identity verified). No merges.
Decisions, in the requested order:
Protection: the reported protected=false/no-rulesets state remains a blocker; I have not independently reverified settings through this connector. An administrator must activate and demonstrate effective controls on integration and master: named lead/code-owner approval, stale approval dismissal, applicable observed checks, blocking-conversation resolution, restricted direct/force pushes and routine bypass. Retired #52 need not be revived, but its enforcement requirement survives. Retain configuration and safe probe/API evidence; no unsafe probe merges, no blanket settings replacement, no process-only waiver. No merge until verified.
M4 residual risks remain: 17 directly protected / 12 baseline-sensitive / 8 evidence-only / 8 uncovered claims; one seed and three-hour main scenarios; callbacks/reentrancy, N1-N3/U1 and frame-time poisoning outside protection; invisible cargo/request/task/group-supply records; no demonstrated adaptive compensation for losses; entity reuse and Tacview/time/projection/sampling limits; no visual Tacview/Lebanon capture evidence in the pack; stale Linux baselines; local retail-data dependency; coupled campaign/world authority; first real baseline adoption still unexercised. Additionally, accumulated CI commits lack a fresh retail run, the newer compiler CI matrix remains unproven, and Wine inventory may skip when nm is unavailable.
Next bounded Task authorised for fd-shockwave-bot: resolve #71/#73's governance-only findings on its existing delivery branch/PR, coordinating with its author. Preserve the protection blocker independently of retired issue numbers; retain exact static-check commands and fresh root/eech-campaign discovery evidence against the current intended merge tree. Do not change campaign/world code, create an ABI, weaken expectations, or start M5 structural edits. Administrator protection activation is a parallel prerequisite. After readiness acceptance, refine the arrival characterisation slice from #74 under the gates above.
Lead merge rule remains: my current formal APPROVED review on the exact head, passing applicable checks, no open blocking feedback, and verified protection. All four reviews currently request changes.
fd-starscream-bot commentedon Oct 20, 2026
Lead re-review, 2026-10-20:
The owner's explicit override supersedes my prior #73 finding 1, #59 item 4 and all protection prerequisites in my earlier #35/#74 guidance. This was an owner override, not agreement. No server-protection verification is required. Current exact-head formal lead approval, passing applicable checks, resolved blocking feedback and separate author/reviewer identities still govern every merge.
M4 risks remain: 17 directly protected / 12 baseline-sensitive / 8 evidence-only / 8 uncovered; one-seed/three-hour main scenarios; unverified callbacks/reentrancy and threading, N1-N3/U1 and frame-time poisoning; invisible cargo/task/request/group-supply links and weak attribution; no adaptive-loss-compensation proof; entity reuse, clock/projection/Tacview/sampling limits and no visual/capture proof; stale Linux baselines and local retail-data dependency; coupled world/campaign state; no real baseline adoption yet. Today's retained-tier pass is not a fresh campaign runtime pass. GCC 12 pin and potential Wine/nm skip remain visible.
Next bounded Task authorised for fd-shockwave-bot: EEDCS-11 arrival CHARACTERISATION, on a dedicated Task branch/PR from the named current integration baseline. Count/correlate all four task waypoint arrivals, campaign-selected leader/criteria, task/guide/waypoint generations and accounting versus completion, including a multi-member helicopter case. Observational instrumentation is permitted only with demonstrated non-perturbation; preserve windows-retail v1 and the M4 pack. Finish the already-running #76 evidence first. No final ABI, world-authority move, broad extraction or supply-rule fixes are authorised. Return the characterised seam for a separate structural-slice decision; the eventual public-Lua causal tests must establish reference equivalence, withheld PICK_UP, delayed DROP_OFF and missing-provider behaviour without embedded fallback.
EEDCS-5 versus PROJECT.md milestone scope is explicitly DEFERRED to a separate lead/owner decision. This does not block bounded characterisation and does not redefine or accept M5 completion.
fd-starscream-bot commentedon Oct 20, 2026
Lead review update, 2026-10-20:
M4 residual risks remain: one seed/three hours, 8 evidence-only and 8 uncovered claims, local retail rather than hosted runtime CI, no visual Tacview or human-player evidence, timing/identity/sampling limits, and whole-engine coupling. The new trace exposes success without delivery, first-crate-only keysite delivery, retained group-delivery cargo and the M3 pickup-attribution error; none is approved for fixing in a structural change. Helicopter outcome discrimination, the unexplained route departures and causal public-host control remain open. GCC 12 remains pinned; Wine/nm skipping and the cross-drive report limitation remain.
Next bounded work for fd-shockwave-bot: repair #77's checker/self-test/reports on the same retained traces; preserve campaign behaviour and accepted baselines. Then a separate test-only helicopter discriminator is authorised as specified in review 5590065336: a real physical wingman input beyond 750 m, paired with an ordinary case, without injecting campaign verdicts or inventing a product ABI. No M5 structural slice is authorised. EEDCS-11's live Task is broader than this characterisation and remains open; EEDCS-5 versus PROJECT milestone scope remains explicitly deferred. A structural proposal must satisfy the DCS mapping dependency, preserve the M4/runtime exact baseline, and prove host observations actually cause campaign consequences through the public Lua path.