Updated Variable Server (markdown)
13a72bf
Created Variable Server (markdown)
601a445
Appendix A: Open work register
Enumerates every item the design doc flags as unimplemented or
deliberately deferred, mapped against open tracker issues so
nothing falls on the floor when implementation begins.
Coverage:
- A.1 Items delivered by #268's PR sequence (no separate trackers
needed).
- A.2 Items #268 enables but doesn't deliver — typed state via
#263 (handled in PR 5 of the migration).
- A.3 Articulated-bodies extension items (Section 15) — most
untracked; lists what needs new issues.
- A.4 Deliberately out-of-scope items with rationale (joint
primitives, slosh, IK, sensor frames, etc.).
- A.5 PR-implementation-time decisions (Reflect derives, naming,
diagnostic wording, etc.) — no trackers needed.
- A.6 Adjacent open issues that may close together with the
articulated-bodies extensions (#198, #206, #199, #163, #65).
- A.7 Summary: five distinct workstreams need new trackers
(mass-tree migration; composite-rigid-body propagation; Bevy
attach/detach momentum conservation + ballistic subtree;
integrator reset on attach (NEW from JEOD precedent);
joint-kinematics driver).
Cross-checked all open issues. Existing trackers found:
- #263 (typed state)
- #198 + #206 (kinematic-only attach to a frame, JEOD's
attach_to_frame path)
- #199 (body-action lifecycle, attach/detach API surface)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
a0205d1
Sections 15.3/15.4: incorporate JEOD precedents
15.3 force/torque routing — large course-correction:
JEOD's stable model is composite-rigid-body integration: only the
root integrates, children are kinematic via DynBody::propagate_state
(dyn_body_propagate_state.cc:526–600). Zero joint, spring, damper,
or constraint primitives in stable code. The experimental
constraints model exists but its README explicitly identifies it
as an unfinished fuel-slosh stub (constrained pendulums for fluid
in tanks), not general articulation.
This narrows the design considerably: the algorithm choice
('Featherstone or composite-rigid-body?') has a default answer
(composite-rigid-body, per JEOD). General-purpose joint dynamics
are out of JEOD's scope; mission code uses ExternalForceC /
ExternalTorqueC. Slosh-style constrained pendulums become a
separate experimental module if needed. Risk drops from medium to
low-medium — the dynamics issue becomes a JEOD port, not fresh
design.
15.4 attach/detach — new gap surfaced:
JEOD's attach (dyn_body_attach.cc:854–862) and detach
(dyn_body_detach.cc:271–273) end with reset_integrators() — the
comment is explicit that 'attachment may cause a jolt to state
integration.' Multi-stage integrators (GJ, ABM4) carry per-body
bootstrap state that becomes invalid on topology change. Today's
Bevy adapter does NOT reset integrator state on attach/detach;
this is a real gap that needs to land alongside the
combine_states_at_attach port.
Also resolves the 'messages vs immediate Commands' sub-question:
messages are fine because staging_system runs before
JeodSet::Integration; the atomicity contract is between steps,
not within commands.
Updates Section 15 summary table risk/status columns and clarifies
'Constraint / joint forces' deliberate-non-goal to cite JEOD's
experimental slosh model as the precedent for any future work.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2ffc511
Section 15.2: follow JEOD precedent — separate mass + frame trees
JEOD maintains three independent TreeLinks instances (RefFrame,
MassBody, MassPoint) and couples them via an explicit back-pointer
(BodyRefFrame::mass_point). The separation is operational too:
DynBody::attach_to does a full mass+frame attach, while
attach_to_frame does a kinematic-only attach with no mass coupling.
This case (a body riding a parent frame without contributing to
the parent's mass) is exactly what would break if mass and frame
shared a single ChildOf relation.
Updates Section 15.2 to flip the earlier 'reuse ChildOf first cut'
lean: the recommendation is now to follow JEOD — frame tree on
ChildOf, mass tree on a separate MassChildOf relation, coupling
via an optional MassPointRef back-pointer on the body's frame
entity. Two attach paths in the Bevy adapter mirror JEOD's two
attach APIs.
The Section 7 FrameStorage trait pattern has a direct MassStorage
analogue, so the algorithm sharing story extends cleanly.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6cc084b
Add Section 15: Articulated-bodies extension
Sketches plausibility for mass/inertia composition, force/torque
routing, and attach/detach at runtime under the ECS-native shape,
so reviewers can confirm #268 doesn't paint future dynamics work
into a corner.
Per topic, captures: status today (runner-only / partial / absent),
ECS-native shape under #268, open questions, risk level, and which
existing test would protect the port (tier3_mass_attach_detach,
the future bevy_parity_mass_attach_detach).
Headline findings:
- 15.1 (kinematic chains): solved by #268 directly; no new
infrastructure beyond what the migration lands.
- 15.2 (mass composition): mechanical port of jeod_dynamics::MassTree
to ECS hierarchy; the FrameStorage trait pattern from Section 7
has a direct MassStorage analogue.
- 15.3 (force/torque routing through chains): largest gap; not in
runner or Bevy; would land as fresh code on top of the ECS
hierarchy in a separate dynamics issue.
- 15.4 (attach/detach): frame-tree half collapses to one-line
ChildOf reparenting; mass-tree + momentum-conservation halves
port from existing runner code.
Updates Section 14's mass-tree bullet to point at Section 15.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
7d450ec
Adopt FrameStorage trait in Section 7
Section 7 originally said 'do not introduce a FrameStorage trait'
and 'the prototype declined to introduce one'. The follow-on
trait experiment (commit 2b0a8ab on study/268-frame-tree-ecs-native)
showed the trait pays off: ~80 lines of duplicated tree-walking
collapse to ~25 lines of trait methods + a one-line delegation,
all 4 prototype parity tests stay bit-identical, two new unit
tests in jeod_frames assert the shared algorithm matches the
arena's inherent methods.
Updates Section 7 to commit to the trait (with explicit notes on
mission-code invisibility and what stays per-consumer), and PR 1's
scope in Section 13 to include the trait + its impls + tests.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
d7547fa
Add Frame-Tree-ECS-Native design doc for issue #268
Architectural design for the long-term ECS-native frame-tree shape:
frames are entities, state lives as components, cross-frame
operations expose as Bevy SystemParams. Includes the 5-PR migration
sequencing, the #263 typed-state tie-in, the Tier 3 risk register,
and the before/after diff demonstrated by the prototype branch
study/268-frame-tree-ecs-native (PR #269).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5731b96
Add Integration-Groups page; cross-link from Home and Strategy §4
Closes the documentation gap from Audit-Findings B2.3 / UTL.10
(tracked as bevy_jeod#210). The page explains how JEOD's
JeodIntegrationGroup concept maps onto Bevy's FixedUpdate schedule:
one tick = one group advance at the schedule's shared dt, multi-stage
integrators (RK4, etc.) are an inner loop inside JeodSet::Integration
rather than multiple schedule passes, multi-body sims need no extra
wiring, and the escape hatch for separate groups is plain Bevy
mechanics (a second schedule on its own cadence; not currently used).
The repo-side rustdoc on bevy_jeod::sets and bevy_jeod::JeodPlugin is
the source of truth for the API; this wiki page is the strategic
explainer that cross-links to it.
Cross-references: JEOD source paths, JEOD_invariants rows
IN.32 / IG.31–33 / DM.04, and Strategy §4 System Pipeline.
Refs simnaut/bevy_jeod#210.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
f942947
Expand Type-System §5 with compile-time-guards cheat sheet
Replace examples that described diagnostics that don't actually fire
today (bare-f64, quat-layout) with examples that do (FrameTransform
composition, time-scale separation, normalization witness, inertial-
flavor distinction). Add §5.1 cheat-sheet table distinguishing wired
vs structural guards, and §5.8 enumerating diagnostics.rs traits that
are scaffolding for future wiring. Fix `Inertial` → `RootInertial`
throughout and expand the frames table with the three kind-distinct
inertial flavors (RF.10).
9de6e3c
Linkify all bare #NNN issue references across wiki
Wiki pages don't autolink issue numbers the way the main repo's
issues/PRs view does. Convert every bare #NNN to an explicit markdown
link to the issue, across Audit-Findings (the new tracking links plus
its bucket-summary), Numerical-Differences, Strategy, Tier3-Regeneration,
Type-System, and Earth-Lighting-Validation.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
b2f1bec
Link Audit-Findings B1/B2 items to tracking issues #198–#211
Each release-blocker (B1) and doc/discoverability (B2) item now shows
its tracking issue number in the heading. Bucket intros point at the
issue ranges.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
e215954
Migrate Strategy, type-system, tier3-regen, numerical-diffs, earth-lighting
Five docs move from the bevy_jeod repo (under docs/ and STRATEGY.md at
root) to the wiki:
- Strategy (was STRATEGY.md)
- Type-System (was docs/type_system.md)
- Tier3-Regeneration (was docs/tier3_regeneration.md)
- Numerical-Differences (was docs/numerical_differences.md)
- Earth-Lighting-Validation (was docs/earth_lighting_validation.md)
Cross-references inside these pages now point at wiki URLs. Existing
wiki pages (Home, Capability-Matrix, Audit-Findings) updated likewise.
The repo retains JEOD_invariants.md because tags like // JEOD_INV: XX.YY
in source are consistency-checked against that catalog and need to stay
next to the code.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
c577897
Redirect stale JEOD_sim_coverage blob URLs to new wiki page
The repo file docs/JEOD_sim_coverage.md is being deleted in
simnaut/bevy_jeod (PR pending) since this wiki page supersedes it.
Update three references in the capability matrix to point at the new
JEOD-Sim-Coverage wiki page instead of the soon-404 blob URL.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0b00209
Add JEOD-Sim-Coverage; update matrix and findings from per-RUN audit
JEOD-Sim-Coverage: per-SIM, per-RUN coverage map for all 70 JEOD SIMs.
Each verdict re-derived by reading both the JEOD input.py config and the
bevy_jeod tier3 test source. Distinguishes JEOD-CSV cross-validation from
analytical-only coverage.
Capability matrix updates from the same audit:
- INT.10 / INT.11 / VRF.cn.01 (contact mechanics): partial -> covered.
5 tier3_contact_* tests cross-validate against JEOD CSVs over 8 RUNs.
- INT.12 / VRF.cn.02 (ground contact): partial -> not covered.
tier3_contact_ground is #[ignore]'d; GroundFacet not yet ported.
- VRF.dyncomp.08 / .09 (RUN_5B / 5C): derived -> covered.
Explicit tier3_simulation_run5b/5c tests exist.
- VRF.ba.01 (SIM_orbinit): covered -> partial. 5 of 46 RUNs CSV-validated.
- VRF.ba.04 (SIM_verif_attach_mass): covered -> partial. 8 of 21 RUNs.
Audit-Findings updates:
- B1.8: rewritten to be specifically about ground-contact GroundFacet
(body-to-body contact is no longer a gap).
- Bucket 3: added orbinit and verif_attach_mass per-RUN gaps.
Home: added link to JEOD-Sim-Coverage; removed link to in-repo
JEOD_sim_coverage.md (which is being deleted from the repo since this
wiki page supersedes it).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2e6e45d
Add pre-release JEOD capability audit (anchored at 587e2e7)
- JEOD-Capability-Matrix: 230-row cross-reference of every JEOD v5.4
capability vs bevy_jeod (38 models, 70 SIMs, 17 data files, 4 benchmarks).
Every tier3_* test is listed in the row it covers.
- Audit-Findings: 49 gaps triaged into release-blockers, doc-blockers,
and accepted-divergence buckets.
- Home: index of wiki pages and links to in-repo reference docs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
be93aaa