# Verification and Acceptance Guide

This document records repeatable checks for reviewers and maintainers.

## Environment

- Documented native baseline: `moon 0.1.20260713`, `moonc 0.10.4`
- CI toolchain: current stable MoonBit release
- Main library target: all standard MoonBit targets
- Preferred and CI build target: Wasm-GC
- Native CLI tested locally with file input on the documented baseline

CI checks the project against the current stable compiler and builds the module's declared `wasm-gc` target. Native CLI behavior is also verified on the documented 0.10.4 baseline. This separation keeps ecosystem compatibility visible without making acceptance depend on a newer Linux Native runtime intrinsic regression.

## Required checks

```text
moon check --deny-warn
moon test --package YeeHh2004/moonrule --deny-warn
moon coverage analyze --package YeeHh2004/moonrule -- -f summary
moon build --target wasm-gc
moon run cmd/main -- test-rules examples/api-validation-rules.json examples/api-validation-cases.json
moon package --list
```

## Functional demonstration

Passing input:

```text
moon run cmd/main -- check examples/access-rules.json examples/user-valid.json
```

Expected result: JSON report with `passed: true`, four passed rules and exit code `0`.

Failing input:

```text
moon run cmd/main -- check examples/access-rules.json examples/user-invalid.json
```

Expected result: JSON report with `passed: false`, four failed rules and exit code `1`.

Explainability:

```text
moon run cmd/main -- explain-file \
  "user.age >= 18 && user.active" \
  examples/user-valid.json
```

Expected result: ordered JSON trace containing source spans, source fragments and intermediate values.

Static analysis:

```text
moon run cmd/main -- analyze-rules examples/access-rules.json
```

Expected result: JSON containing per-rule AST statistics, referenced paths, called functions, estimated cost, and findings.

Static-analysis admission gate:

```text
moon run cmd/main -- lint-rules examples/api-validation-rules.json
```

Expected result: JSON with `passed: true`, six accepted rules, and exit code `0`.

Business-format validation and optional paths:

```text
moon run cmd/main -- check examples/api-validation-rules.json examples/api-request-valid.json
moon run cmd/main -- check examples/api-validation-rules.json examples/api-request-invalid.json
```

Expected result: the first request passes all six rules with exit code `0`; the second fails all six with exit code `1`.

Batch validation:

```text
moon run cmd/main -- check-batch examples/access-rules.json examples/users-batch.json
```

Expected result: three item reports, two accepted records, one rejected record, and exit code `1`.

Rule regression suite:

```text
moon run cmd/main -- test-rules examples/api-validation-rules.json examples/api-validation-cases.json
```

Expected result: four matched cases, zero mismatches, complete per-rule outcomes, and exit code `0`.

## Test coverage areas

- tokens, operators, escapes and lexical failure spans;
- parser precedence, paths, indexing, calls and array literals;
- arithmetic, comparison and membership;
- boolean short-circuit behavior;
- string, collection and regex built-ins;
- missing fields, type mismatch and non-boolean outcomes;
- multi-rule compilation and complete reporting;
- trace ordering and short-circuit trace behavior;
- JSON configuration round trips;
- compile-time source length, AST node count and depth limits;
- evaluation step limits and short-circuit budgeting;
- static-analysis findings and rule-set aggregation;
- severity thresholds, fail-fast behavior and batch reports;
- rule-set configuration limits and duplicate-name detection;
- 25-function metadata catalog and additional safe-access, numeric and predicate functions;
- optional member/index access, including null propagation and index short-circuiting;
- ISO date, RFC 3339 timestamp, IPv4, email, UUID, and SemVer boundaries;
- analysis-policy limits, validator findings, and rule-set admission aggregation;
- regular-expression pattern and input safety limits;
- regression-suite decoding, configuration limits, exact failed-rule matching, and evaluation-error handling.

On 2026-07-27 with MoonBit 0.10.4, the package suite reported 97/97 passing MoonRule tests. Coverage analysis reported 1,588/1,718 covered executable lines (92.4%). The repository contains 5,803 physical lines across 39 MoonBit source, test, benchmark, and CLI files, including 4,418 production lines. Run the commands above to reproduce these measurements; generated traces and local dependency workspaces are not committed.

On Windows, the coverage command may also print a platform-detection failure from the transitive `moonbitlang/x` dependency (`is_windows platform detection`). It does not belong to MoonRule's package tests; verify MoonRule itself with the explicit package test command above.

For maintainers validating the Native CLI on the documented baseline, run `moon build --target native`. The current CI uses Wasm-GC because that is the module's preferred target and avoids a Linux Native linker incompatibility involving `moonbit_get_cli_args` observed with MoonBit 0.10.7.

The GitHub Actions workflow retains `test-results.txt`, `coverage-summary.txt`, and `regression-report.json` for 30 days in the `moonrule-acceptance-records` artifact. This provides downloadable evidence for each pushed commit and pull request instead of relying only on console output.

## Release checklist

- all checks above pass with no warning;
- public interface file is regenerated with `moon info`;
- `CHANGELOG.md` matches the release version;
- README examples remain type checked;
- package contents contain no build outputs, credentials or local dependencies;
- module owner and repository URL are updated;
- version follows semantic versioning;
- release is published to mooncakes.io.