AGENTS.md@editor · git:20261015.49a4db2 · 2026-10-15 · sha256 f2a0bc26dafa14c0

AGENTS.md@editor git:20261015.49a4db2A

Immutable. This exact content never changes and is served at /api/v1/blob/f2a0bc26dafa14c0.

# Agent Notes

## Start Here

- Architecture and dependency rules: `docs/architecture.md`
- Package contracts: the owning package's `README.md` and
  `pkg.generated.mbti`
- Commands and test-layer selection: `docs/harness.md`
- Required checks and conformance-test rules: `docs/quality.md`
- Style: `docs/styles.md`
- Active cross-package plans and planning rules: `docs/exec-plans/`
- Monaco/CodeMirror source maps: `docs/references/{monaco,codemirror}.md`

## UI Development Loop

OpenSeek's desktop file editor (`../desktop/frontend/fileeditor`) is the primary
downstream, user-facing host. `internal/shell` is the fast development and E2E
host for the editor. Use it for the routine editor UI build-and-preview loop.

- For a visual or behavioral improvement to existing Viewer UI, implement and
  preview it in `internal/shell`, keep the existing public host seam stable, and
  expect OpenSeek to receive the change with at most a small adapter change.
  When broader adaptation appears necessary, inspect the coupling before
  expanding either host API.
- For a new editor UI intended for OpenSeek, inspect
  `../desktop/frontend/fileeditor/{editor_panel,viewer_services}.mbt` and the
  relevant provider/capability adapters before finalizing the public contract.
  New user-facing Viewer features target OpenSeek by default; an explicit
  editor-only exploration has its stated scope. Build the generic editor
  surface and its `internal/shell` preview first, then complete the OpenSeek
  adapter required by the feature in the same implementation task. Separate
  coherent commits are fine.
- Keep OpenSeek product policy, host RPC, storage, and workspace behavior under
  `../desktop/**`. Keep the editor API host-neutral, and use `ViewerServices`
  and the public `viewer/common/**` capability handles as the integration seam.
- During iteration, run focused editor tests/browser scenarios and a targeted
  JS check of every touched OpenSeek adapter package. Run the required editor
  and root integration gates before declaring the cross-host work complete;
  package or launch the full desktop app only when OpenSeek-specific layout,
  effects, assets, or packaging are part of the behavior under test.

## Architecture Changes

For dependency or public API changes, follow `docs/architecture.md`, review the
affected `moon.pkg` files, and inspect the owning `pkg.generated.mbti`. Introduce
architecture automation when the same concrete boundary violation has recurred;
make the check express that boundary independently of current method or type
names.

## Reference Ports

Follow `docs/exec-plans/_PORT_PLAYBOOK.md` for Monaco/VS Code or CodeMirror
ports. Use the selected upstream behavior as the oracle and choose MoonBit
representations to implement that contract. Within the selected port scope:

1. Choose and state the port mode: behavior port by default, algorithm-fidelity
   port for sensitive arithmetic/state machines, or full source audit only when
   explicitly requested.
2. Account for observable behavior, boundary cases, algorithmic invariants, and
   intentional exclusions at the behavior or branch-cluster level. Use a
   per-member ledger when the selected full-audit mode requires it.
3. Preserve exact control flow and constants only where they affect the selected
   algorithm-fidelity contract. Otherwise prefer MoonBit-native concrete types,
   enums, handles, callback records, and ownership.
4. Link each claimed behavior to focused evidence or mark it `DEFERRED (reason)`
   / `N-A (reason)`. Use repository checks for integration and focused evidence
   for the claimed behavioral parity.

## Execution Plan Continuation

When the user asks to execute a checked-in plan, carry its agreed scope through
inventory, review, implementation, validation, and milestone commits. Treat
the plan's review gates as internal quality checkpoints: produce the required
artifact, review it against the plan and current source, record the result,
and continue.

Pause only when the user explicitly requests a review stop or when the gate
reveals a material choice that the plan and current repository evidence cannot
resolve without changing scope, public API, or behavior.

## Version Control

- For implementation tasks, commit each coherent, validated milestone as part
  of delivery.
- Preserve existing history by default. Rewrite or revert it when the user has
  authorized that operation.