8 added, 0 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.
- 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.
+ - OpenSeek's desktop file editor is the primary downstream, user-facing editor
+ host. Use `editor/internal/shell` as the fast build-and-preview loop for
+ editor UI work. Existing Viewer UI improvements should flow into OpenSeek
+ through its current public APIs with little or no host adaptation. When a new
+ editor UI is intended for OpenSeek, implement the corresponding
+ `desktop/frontend/fileeditor` adaptation in the same task; do not make the
+ slower full desktop build and preview the routine editor inner loop.
+
- 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.