hatake業務システムを「定義」で作る

画面・サーバの検証・権限・API の形・設計書・試験まで、同じ1枚の定義から。UI コードではなく定義を書く（AI に書かせるのも定義）。Flutter / Vue / React は描画に使う実装技術であって、書く対象ではない。

機能別の書き方

動くデモを見る

貼って試す

AI に書かせる

定義が唯一の正

画面は PageDefinition に集約される。YAML / JSON / API のどれで持ってきても、内部では同じ定義に収束する。

バックエンドを選ばない

Spring Boot / ASP.NET / Node / Laravel / Firebase / Supabase。Framework が知っているのは Repository のインタフェースだけ。

描画は差し替えられる

Flutter（Material3）・Vue 3・React 19 で同じ定義から同じ画面。Renderer は定義を描画するだけで業務ロジックを持たないので、Fluent や Cupertino にも替えられる。

サーバも同じ定義で判断する

検証・問い合わせ・権限（開ける画面・押せるボタン・見せる項目・受け取る項目）を、画面と同じ定義から Java / TypeScript で。画面とサーバで規則がずれない。

AI が書きやすい

仕様は機械可読（JSON Schema・キー索引・間違いカタログ）。MCP サーバ経由で、実装を読ませずに定義を書かせられる。

定義1枚で、この画面ができる

一覧・並べ替え・行の編集削除・入力フォーム・必須チェックまで、これで全部。Dart は1行も書かない。

yaml

# yaml-language-server: $schema=https://github.com/ASIL-E-Hatake/hatake/raw/main/spec/hatake-page.schema.json
# hatake — MasterPage example: 部門マスタ (Department master)
dsl_version: "1.0"

page:
  type: master
  id: dept_master
  title: 部門マスタ
  repository: deptRepository
  key: code

  # 選択肢を**マスタから引く**例（`optionsSource`）。定義に並びを書けないもの
  # ── 取引先・商品・部署のように増える表 ── はこちら。Framework は HTTP も SQL も
  # 知らない＝一覧と同じ `search` を Repository に投げるだけ。
  search:
    filters:
      - { field: name, label: 部門名, type: text, operator: contains }
      - field: parentCode
        label: 上位部門
        type: select
        operator: equals
        # 検索条件でも入力欄と同じキーが同じ意味で効く。
        optionsSource:
          repository: deptRepository
          value: code
          label: name
          limit: 200
        # 見せ方の設定は `config`（Renderer とプラグインが読む）。
        config: { placeholder: すべて }

  table:
    rowActions: [edit, delete]
    columns:
      - { field: code, label: 部門コード, sortable: true }
      - { field: name, label: 部門名 }

  form:
    sections:
      - title: 基本情報
        fields:
          - { field: code, label: 部門コード, type: text, required: true }
          - { field: name, label: 部門名,     type: text, required: true }
          # 上位部門は自分自身のマスタから引く。
          - field: parentCode
            label: 上位部門
            type: select
            optionsSource:
              repository: deptRepository
              value: code
              label: name
              limit: 200
          # 部門長は**選んだ部門に属する人**だけを出す（`parentKey` で親の値が
          # 絞り込み条件として渡る＝`{ deptCode: <上で選んだ値> }`）。
          - field: managerNo
            label: 部門長
            type: select
            optionsFrom: code
            optionsSource:
              repository: employeeRepository
              value: employeeNo
              label: employeeName
              parentKey: deptCode
              limit: 100

  actions:
    - { id: create, type: create, label: 新規登録 }

書いたら推測で終わらせずに検証する。知らないキーは黙って捨てられるので、「書いた気になって効いていない」を防ぐのはこれ。

bash

npx -p @hatake-fw/api hatake validate dept_master.yaml

何がどこまでやるのか

定義から画面まで

人と AI が書くのは定義だけ。PageDefinition が唯一の正で、Renderer は業務を知らない。データの流れと層の責務も図解にある。

インストールせずに触る

上の YAML を貼って、その場で画面にできる場がある。プレイグラウンド。

直すとその場で描き変わる。データは定義から作った仮のもの（Repository を書かなくていい）
綴りを間違えたらその場で理由が出る（sortble → sortable の間違い？）
作った定義は URL で渡せる（?yaml= に載る）ので、そのままレビューに貼れる

ブラウザだけで動く（Flutter Web）。インストールも登録も要らない。

次にどこを見るか

やりたいこと	行き先
案件を始める（画面を書く前に決めること）	先に決めること
「こうしたい」から書き方を引く	機能別の書き方
全体像を絵で見る	図解
動いている画面を触る	デモ（右下の札で役割を切り替えると、隠れる列・出ないボタンが見える）
自分で書いた定義を試す	プレイグラウンド
自分の AI に hatake を書かせる	AI に書かせる
導入手順・仕組み・写経用サンプル	GitHub のドキュメント

この Framework が持たないもの

業務ロジック、ワークフローエンジン、DB、認証、認可、バックエンド API、ORM。持たないと決めているので、そこは普通に自分のコードで書く。

この境界は散文ではなく引ける表にしてある。「これは定義で書けるのか、自分で書くのか」を1発で。

bash

npx -p @hatake-fw/api hatake where 締め処理        # → 枠組みの外（なぜ持たないか＋画面側でできること）
npx -p @hatake-fw/api hatake where 一覧の並べ替え   # → 定義で書ける（書くキーと次に引く道具）

AI に「締め処理も作って」と頼むと、外だと言えないまま Dart を書き始める。それを止めるための表で、MCP なら hatake_where として渡る。詳しくは先に決めることと仕組みと責務分担。