Implementation proceeds by dependency layer, not by feature. Layers L2a / L2b / L4 are mutually independent and can be built in parallel once L1 is done.

Fully local, zero external service connections, end-to-end verifiable via debug_* MCP tools and seed fixtures.

Adds the multi-LLM parser pipeline and the LINE bot entry point (real LLM + LINE messaging quota apply here).

Already delivered after MVP-2: Web UI and per-user Web ledger, Google/password/UID authentication, sharing, iCal subscription, Google Calendar push sync, generic update/delete, production Web API, remote MCP mode, and installable PWA delivery with an explicit update flow.

Remaining product candidates: bookmarklet entry point and weather-aware deadline notices. Production acceptance checks are tracked in docs/VERIFICATION.md, not as new implementation layers.

Email-forward intake (owner 2026-07-27: 「メールの内容をコピーするのではなく転送してもらうとかがいいな」): the backend is done — POST /webhook/email receives Resend's inbound webhook (src/web/email-intake.ts), verifies the Svix signature over the raw body with a 5-minute replay window (src/web/email-signature.ts), resolves the ledger from the per-user receive address p-<mailSecret>@PLANCEL_INBOUND_DOMAIN — never from the forgeable from — reads the body through Resend's Received-Emails API, runs the SAME parser chain as /api/parse and LINE, and creates a candidate through the same createReservation + calendar-sync hook, filling an unstated policy from the facility template. Anti-abuse: a per-user 24h cap (PLANCEL_MAIL_DAILY_CAP, default 50), a 64KiB raw-body ceiling, a 100KB parser input ceiling, and ["mail_seen", <email_id>] claimed atomically so a redelivery can never create a second reservation. Everything the app decides answers 200 so Resend stops retrying; an unparseable forward writes nothing and tells the forwarder over LINE when they are linked. The UI is done too (2026-07-28): マイページ shows the address with copy and 再発行 controls, and 「取り込む」 opens the same address inline as 「📨 メールを転送する」 so it is offered where a reservation is actually added. Forwarding is the one intake route with no confirmation screen, which both surfaces say. Ops setup (Resend receiving + webhook + the two env vars) is in docs/DEPLOY.md §3.1. Remaining: a real forwarded mail has not yet been run through production end to end.

Facility policy templates (owner 2026-07-27: 「ホテルごとに規定(ベース)を設定できるといいかも。プランごとになるかもだけど基本的に同じことが多いため」): the backend is done — a per-ledger library keyed by the normalized facility name (src/web/policy-template.ts), its four HTTP routes under /api/policy-templates, and the matching remote-MCP tools. The web UI is done (2026-07-28): the add/edit form looks the facility up and pre-fills the fee table, offers the 「この施設の規定として覚える」 save, and マイページ lists the saved defaults for deleting. The 「fill it only when the policy is unknown」 rule now lives once, in createReservation (src/web/store.ts), so every intake route — web form, MCP, mail forward, LINE — applies it identically; it used to be written per-route, and LINE and MCP had simply been missed.

Share roles (owner 2026-07-28: 「招待する時に編集を許可すれば細かい修正を参加者もできるように」): the backend is done — a viewer/editor role on the membership (src/web/sharing.ts), the role parameter on POST /api/reservations/:id/members, the new owner-only PATCH /api/reservations/:id/members/:userId, an editor's PATCH applied to the OWNER's ledger with the same calendar-sync hook, updated_by attribution on every reservation write, and the matching remote-MCP tools. The invite UI is done (2026-07-28): the invite box carries the 「編集を許可」 checkbox, the member list shows each role and can switch it, and a shared row is editable for an editor (the list response carries shared.role). 確定・キャンセル・削除・招待 stay owner-only, and the 使い方 says so — confirming settles the whole plan and deleting cannot be undone.

Weather integration (ADR-8): JMA public JSON (key-free, effectively rate-limit-free) behind a WeatherProvider interface (+ Mock/replay, same discipline as Parser/Notifier). Weather enriches notification messages and adds a weather_alert trigger (typhoon approach × unsettled candidates × before free-cancellation deadline). Core fire-decision stays weather-free and pure. New design point: forecast-revision re-notification needs a forecast-generation component in the idempotency key. Key insight: the value is highest when the free-cancel deadline falls outside the reliable forecast window (~5-7 days) — the UI/notification should present the loss curve as an insurance decision, not a weather report.

Purpose of the LINE channel: (1) push deadline reminders / notices to each user's own LINE (primary), (2) let each user check, update, and narrowly add reservations from LINE (secondary). Every plancel user has their own LINE account, so the binding is a per-user link (2026-07-27) — not one env-configured owner. Status and remaining work, in priority order:

Browser extension, direct Gmail reading, paid LLM tiers, public release.

See specs/plancel/design.md (§ Implementation Order) and docs/SDD.md (§9 フェーズ計画) for the authoritative source of this plan.