# Positioning

Lampo is **MoonBit for WeChat MiniApp Skyline**.

Authors write pure Elm-style business logic in MoonBit; Lampo lowers it into
reviewable Skyline MiniApp artifacts and a generated JavaScript bridge, with
release-visible diagnostics.

## Product Pipeline

```text
pure Elm-style MoonBit authoring
-> component-scoped runtime state
-> MiniApp runtime commands
-> generated Skyline MiniApp artifacts
-> generated JavaScript bridge
-> setData and wx.* adapters
```

```text
Model + Msg -> update -> Model
Model -> view
Cmd -> Msg
```

## Scope

Lampo targets WeChat Mini Program artifacts for the **Skyline** renderer.

Supported product surface:

- Pure Elm-style MoonBit authoring (`Model`, `Msg`, `update`, `view`, commands)
- Generated Skyline project files (`app.json`, page JSON/WXML/WXSS/JS, runtime
  bundle, project config, review manifests)
- TailwindCSS utility classes from MoonBit view code, lowered through
  `weapp-tailwindcss`
- Generated bridge ownership of `setData`, lifecycle wiring, event dispatch,
  and typed `wx.*` adapters
- Local CLI (`lampo`), fake-host tests, page smoke, and the release gate
  `vp run check:mvp`

Authoring and style rules that stay intentional:

- ordinary apps do not use user-facing `Signal` / patch APIs or direct `setData`
- arbitrary handwritten semantic WXSS is not Lampo's public style system
- React/Vue-compatible runtime APIs are not part of the product surface
- Lampo is not a cross-platform JavaScript framework

## User-Facing vs Runtime

Application authors should write MoonBit structs, enums, pattern matching,
immutable updates, typed commands, and view helpers.

The runtime may use mutable cells, queues, caches, generated metadata, and
bridges internally. Those are not the default user API.

## Reference Boundaries

These workspace references inform design; they are not Lampo products:

- **Luna** — signal / fine-grained runtime reference; not the public authoring
  model
- **Rabbita** — DSL / authoring ergonomics reference; not a DOM product to ship
- **weapp-vite** — MiniApp engineering / host-lifecycle reference; not Lampo's
  host runtime

## Capability Expansion: WeChat AI

The primary **capability expansion** is integrating with WeChat Mini Program
**AI development mode (beta)**: expose MiniApp business as agent-callable
**SKILL**s (atomic APIs / components with `SKILL.md` + `mcp.json` schemas),
while keeping Skyline generation as the delivery surface.

Why Lampo is a strong fit:

- Elm-style `Model` / `Msg` / `update` already isolates intent as testable
  transitions
- Typed capability commands, phases, and diagnostics match schema-driven
  atomic API contracts
- Reviewable generated Skyline artifacts support page handoff and help auto
  mode’s structure-sensitive parsing
- Backend-required boundaries (session exchange, payment signing) stay explicit
  when an agent may trigger fulfillment

Official landscape (auto mode + developer mode, SKILL package layout, beta
status) and deferred implementation queue: `docs/wechat_ai_direction.md`.

**Boundary for `0.1.0`:** direction is locked; generating `agent.skills` /
`mcp.json` / SKILL packages is **not** shipped yet. WeChat AI access itself
remains platform beta.

## Tooling Honesty

- Local `lampo` CLI (`scripts/lampo.mjs` / `vp run script -- scripts/lampo.mjs`)
  and `vp run check:mvp` are the supported day-to-day check path inside this
  repository
- The current MoonBit toolchain accepts `--deny-warn` on `moon check` and
  `moon test`, but not on `moon fmt` or `moon info`. The review gate therefore
  uses `moon fmt --check`, `moon check --deny-warn`, `moon info`, and
  `moon test --deny-warn`.
- Today `lampo init` joins the new app into a local `moon.work` with the Lampo
  repo root so `lampclaw/lampo@0.1.0` resolves from workspace sources — that is
  intentional for development before a registry cut
- Contest source review can use this repository directly: run
  `vp run check:mvp` and inspect the committed MiniApp `dist/` projects. A
  separate registry-distribution review requires **`moon publish`**
  `lampclaw/lampo@0.1.0` to **mooncakes.io** first, then an app path that
  resolves `lampo` from mooncakes rather than a local monorepo workspace bind.
  A dedicated `--deps mooncakes` option, or a default flip, belongs to that
  publish follow-up batch
- WeChat Developer Tools CI automation is not part of the product promise
- `package.json` is a private, unversioned JS tool shell and is **not** an npm
  publish target

## Product Version

Product version is **`0.1.0`**, defined by `moon.mod` and `CHANGELOG.md` on
`main`. Version git tags are not used.

Contest pin: `docs/contest_submission.md`.

## Further Reading

- `docs/wechat_ai_direction.md`
- `docs/roadmap.md`
- `docs/miniapp_host_capabilities.md`
- `docs/miniapp_runtime_export_plan.md`
- `docs/contest_submission.md`
- `docs/mvp.md`