Skip to content

History

Revisions

  • Updated Variable Server (markdown)

    @simnaut simnaut committed May 6, 2026
    13a72bf
  • Created Variable Server (markdown)

    @simnaut simnaut committed May 6, 2026
    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>

    Test User committed May 3, 2026
    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>

    Test User committed May 3, 2026
    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>

    Test User committed May 3, 2026
    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>

    Test User committed May 2, 2026
    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>

    Test User committed May 2, 2026
    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>

    Test User committed May 2, 2026
    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>

    Test User committed May 2, 2026
    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).

    Test User committed May 2, 2026
    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>

    Test User committed Apr 28, 2026
    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>

    Test User committed Apr 28, 2026
    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>

    Test User committed Apr 28, 2026
    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>

    Test User committed Apr 28, 2026
    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>

    Test User committed Apr 28, 2026
    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>

    Test User committed Apr 28, 2026
    be93aaa
  • Initial Home page

    @simnaut simnaut committed Apr 28, 2026
    613ab92