9 added, 2 removed. Audit A to A.
# Project Agents.md Guide
This is a [MoonBit](https://docs.moonbitlang.com) project.
You can browse and install extra skills here:
<https://github.com/moonbitlang/skills>
## Project Structure
- MoonBit packages are organized per directory; each directory contains a
`moon.pkg` file listing its dependencies. Each package has its files and
blackbox test files (ending in `_test.mbt`) and whitebox test files (ending in
`_wbtest.mbt`).
- In the toplevel directory, there is a `moon.mod` file listing module
metadata. `moon.mod.json` is the legacy manifest format.
## Coding convention
- MoonBit code is organized in block style, each block is separated by `///|`,
the order of each block is irrelevant. In some refactorings, you can process
block by block independently.
- Try to keep deprecated blocks in file called `deprecated.mbt` in each
directory.
## Tooling
- `moon fmt` is used to format your code properly.
- `moon ide` provides project navigation helpers like `peek-def`, `outline`, and
`find-references`. See $moonbit-agent-guide for details.
- `moon info` is used to update the generated interface of the package, each
package has a generated interface file `.mbti`, it is a brief formal
description of the package. If nothing in `.mbti` changes, this means your
change does not bring the visible changes to the external package users, it is
typically a safe refactoring.
- In the last step, run `moon info && moon fmt` to update the interface and
format the code. Check the diffs of `.mbti` file to see if the changes are
expected.
- - Run `moon test` to check tests pass. MoonBit supports snapshot testing; when
- changes affect outputs, run `moon test --update` to refresh snapshots.
+ - Use `moon test` for package- or workspace-scoped MoonBit tests. MoonBit
+ supports snapshot testing; when changes affect outputs, run
+ `moon test --update` to refresh snapshots.
+
+ - From the repository root, the integration gates are `just check`, `just
+ test`, and `just build`. They cover the root workspace's native and JS
+ targets; `just test` also runs the offline OpenSeek cram tests. For changes
+ under `editor/`, also run `just editor-test` for its all-target suite; for
+ browser behavior, run `just editor-test-browser` as well.
- Prefer `assert_eq` or `assert_true(pattern is Pattern(...))` for results that
are stable or very unlikely to change. Use snapshot tests to record current
behavior. For solid, well-defined results (e.g. scientific computations),
prefer assertion tests. You can use `moon coverage analyze > uncovered.log` to
see which parts of your code are not covered by tests.