一键导入
dart-architecture
DART Architecture: the DART 7 multi-physics, multi-solver, multi-backend simulation pipeline and where each abstraction is owned
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
DART Architecture: the DART 7 multi-physics, multi-solver, multi-backend simulation pipeline and where each abstraction is owned
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
DART Analyze: analyze repository evidence without editing
DART Audit Agent Compliance: audit and fix gaps when agents miss or cannot discover documented rules
DART Backport PR: backport a merged main PR to a release branch
DART Benchmark Packet: author or refresh a benchmark evidence packet for an owning plan
DART Branch Cleanup: analyze or clean stale repository branches
DART Build: CMake, pixi, dependencies, and build troubleshooting
基于 SOC 职业分类
| name | dart-architecture |
| description | DART Architecture: the DART 7 multi-physics, multi-solver, multi-backend simulation pipeline and where each abstraction is owned |
Load this skill when working on the DART 7 simulation World, on
solvers/physics domains/compute backends, or whenever a task needs the
big-picture map of how DART 7 is generalized for multi-physics, multi-solver,
and multi-backend simulation.
The World owns topology, time, and a configured set of solvers; each
solver advances the dynamics of the entities in its physics domain, and
couplers mediate interactions between domains — with parallelizable work
expressed as compute-graph nodes that any backend executor runs.
Users configure method families and policies, never solver registries,
component storage, or execution backends.
docs/readthedocs/architecture.md is the single-page map of the design and
the options at each seam, with honest status markers.
docs/design/dart7_architecture_assessment.md is the verified record of
where the implementation still diverges from that design (no internal solver
contract yet, conceptual-only Model/State split, executor seam unused by
dynamics stages, missing apples-to-apples substrate) and owns the standing
rule: new solver families enter only through
docs/plans/solver-family-intake.md, including contract conformance and
machine-recorded solver identity in all benchmark evidence. PLAN-091 retired
the first living hardening packet plan; current follow-up work routes through
docs/plans/dashboard.md, the intake checklist, and the durable owner docs
named in the assessment. Do not write new code that copies a pattern the
assessment still lists as a verified finding.
The architecture page's Source-of-truth map is the single owner of the full topic → owner-doc mapping (solver, API, extension, compute, differentiable, clean-break, north-star). The docs an agent most often needs inline:
| Topic | Document |
|---|---|
| Solver abstraction, domain assignment, coupling, schedule | docs/design/simulation_solver_architecture.md |
| Verified findings, standing rule, competitor lessons | docs/design/dart7_architecture_assessment.md |
| Public C++ / dartpy API shape and promotion rules | docs/design/simulation_cpp_api.md, docs/design/simulation_python_api.md |
| CPU / SIMD / GPU decision framework | docs/design/scalable_compute_decisions.md |
| DART 7 vs DART 6 topology · live progress / parity gates | docs/design/dart7_clean_break_strategy.md, docs/plans/dashboard.md |
Solver, Coupler, PhysicsDomain, ECS storage, component
types, executor/backend types, or solver registries as public API.World + addRigidBody/addMultibody + step) free of
solver vocabulary.Use docs/ai/verification.md to select the docs-only or code gate set for the
change. Implementation work that realizes parts of this architecture also
follows the gates in docs/design/simulation_solver_architecture.md, the
solver-family intake checklist, and any active owner plan named in
docs/plans/dashboard.md.