TenonAdmin の公開リファレンスアプリ：パッケージを入れ、本番に載せ、今すぐ触れる本物のバックオフィス。
🔗 オンラインデモ · 📦 TenonAdmin 本体 · 📋 実行台帳
TenonAdmin を入れただけの、ごく普通の業務システムです。カーネルの一部ではありませんし、「デモのために」書かれた行は一つもありません——TenonAdmin を採用したあなたのコードも、こう見えるはずです。
存在理由は「試す価値があるか判断するために、まず 3 日ドキュメントを読む」という手順を省くこと。触れるデプロイがあり、クローンして動かせるリポジトリがあります。CRM は最初の業務モジュールで、この先さらに増えていきます。再利用可能なカーネル機能はここでは一切開発しません。それは TenonAdmin リポジトリの担当です。
オンラインデモに以下のいずれかのアカウントでログインし、**客户管理（顧客管理）**を開いてください：
| アカウント | パスワード | データスコープ | 件数 | ほかに見えるもの |
|---|---|---|---|---|
总部管理员（本社管理者） |
Trial@123456 |
全組織 | 214 | CRM ＋ システム管理一式 |
华南区域经理（華南地区マネージャー） |
Trial@123456 |
華南地区とその配下 | 128 | CRM のみ |
深圳专员（深圳担当） |
Trial@123456 |
深圳支店のみ | 42 | CRM のみ |
superAdmin |
非公開（ローカルでは TenonAdmin:Seed:AdminPassword の値） |
無制限 | 214 | 全モジュール、全ボタン |
3 つの数字は同じエンドポイント、同じフロントエンドコードから出ています。しかも、それを叩く CustomerService には組織フィルターが 1 行もありません。カーネルがビジネスコードの外側でフィルターを掛けているからです。どこで掛かっているのか、そしてなぜそれが「数行短く書ける」よりはるかに価値があるのかは、同じクエリ、3 つの数字（中国語）にまとめてあります。
体験用の 3 アカウントは顧客エンドポイントに読み取り権限しか持たないため、追加・編集・削除ボタンはそもそもレンダリングされません。本社管理者はさらにカーネル標準のシステム管理メニュー一式を持っていますが、これはスーパー管理者のバイパスではなく通常のロール付与によるものです。まさにその経路を見せるためのリポジトリなので、superAdmin は公開デモに出しません。[RolePermission] を迂回するため、パスワードを公開すれば全訪問者にスーパー管理者を渡すのと同じだからです。ログインページにはこの 3 つのワンクリックボタンがあるので、パスワードを打つ必要はありません。
.NET 10 SDK が必要です。フロントエンドも動かすなら Node.js 22 も。
docker compose up -d --buildMySQL、Redis、バックエンド、Caddy 配信のフロントエンドが一度に立ち上がります。フロントエンドは TENON_WEB_PORT（デフォルト 8090）で待ち受け、/api と /health* をバックエンドへリバースプロキシします。シークレットとポートは docker-compose.yml の隣に置く .env で上書きしてください（TENON_DB_PASSWORD、TENON_JWT_SECRET、TENON_ADMIN_PASSWORD、TENON_API_PORT、TENON_WEB_PORT）。実際の値は絶対にコミットしないこと。
dotnet restore
dotnet build -c Release
dotnet runデフォルトは SQLite なので、先に DB を用意する必要はありません。初回起動でスキーマを作成し、シードデータを投入し、ランダムな管理者パスワードをコンソールに出力します。起動後は /health、/health/ready、/openapi/v1.json にそのままアクセスできます。
Properties/launchSettings.json は削除しないでください。これが ASPNETCORE_ENVIRONMENT=Development を固定しています。無いとホストは Production として解決され、CodeFirst の自動スキーマ作成が設計上オフになり、シードテーブルが無いまま起動に失敗します。経緯は v0.3.2 アップグレード記録に。
フロントエンドは別のターミナルで。バックエンドの検証プロセスとメモリを取り合わせないように：
Set-Location web
npm install
npm run gen:api
npm run devdev サーバーが API と OpenAPI コントラクトを http://localhost:5100 へプロキシします。コミット前に走らせるのは npm run typecheck と npm run lint の 2 本。
顧客インポートはデフォルトで dry-run（CrmDemo:ImportDryRun=true）です。体験アカウントはアップロード / プレビュー / 検証 / 送信まで一通り使えますが、送信結果は「DB に書いていない」と明示されます。エクスポートは一覧と同じクエリで、データ権限も効いたままです。
公開デモではさらに CrmDemo:ReadOnly（DemoReadOnlyFilter）を有効にしています。ログインとインポート以外の非 GET はすべて 403 / 41002 を返します。メニューもボタンもフォームも今までどおり描画され、押せます。DB に届かないだけです。上の体験用 3 アカウントのパスワードは公開されているので、公開デモを守っているのはパスワードではなくこのゲートです。 カーネルの TenonAdmin:DemoMode で代用しないでください。あちらは許可リストを持たず、インポートの POST まで止めてしまいます。
ローカルでは ReadOnly はデフォルト false なので、スーパー管理者を含む 4 アカウントとも実際に追加・編集・削除できます。ImportDryRun=false にすればインポートも本当に書き込みます。
ホストに TenonAdmin.Workflow@0.7.1 を登録し、Vue に定義/デザイナー、申請、未処理、CC、自分の申請、処理済み、監視、長期委任の画面を追加しました。フレームワークのメニュー所属を維持します：管理は System、社員の承認は Business、CRM は引き続きモジュール 1000 です。
専用のローカルロールに必要なメニューだけを付与します。公開トライアルアカウントに新しいワークフロー権限は付与しません。CrmDemo:ReadOnly はワークフローの書き込みも拒否します。今回の隔離環境での人工承認は顧客情報変更の承認ではなく、オンラインデモへのデプロイも行っていません。検証記録とコマンドを参照してください。
0.7.0 の通常管理者の権限問題は、正式版 0.7.1 と対応する Vue の権限チェックで修正されました。通常管理者による設計・承認者指定・公開をローカルで再検証しました。検証範囲はアップグレード記録を参照してください。
現在は安定版 0.7.1 に固定しています。NuGet の TenonAdmin / TenonAdmin.Excel / TenonAdmin.Workflow / TenonAdmin.Templates が 0.7.1、ソースは tag v0.7.1；ワークフロー画面と必要な共通差分を Tenon-Net/TenonAdmin/web#v0.7.1 から既存 Vue アプリへ移行（CRM・クイックログイン・ブランド・ツールチェーンを維持）。詳細は v0.7.1 アップグレード記録。
tenon-example.csproj のバージョンは、この段落と厳密に一致していなければなりません。カーネルがリリースされるたびにここも上げて検証し直します——このリポジトリはカーネルの常設インテグレーションカナリアも兼ねており、バージョンが古いカナリアは籠に入っていないのと同じだからです。
基本テンプレートのみ（CRM・ワークフローの接続は含みません。このアプリは本リポジトリを clone して実行）：
以下は新しい空のディレクトリ専用です。このアプリのカスタマイズ済み web/ を上書きしないでください。ワークフローには検証記録に記載したホスト登録も必要です。
dotnet new install TenonAdmin.Templates@0.7.1
dotnet new tenon-app --output tenon-example
Set-Location tenon-example
dotnet add package TenonAdmin --version 0.7.1
dotnet add package TenonAdmin.Excel --version 0.7.1
dotnet add package TenonAdmin.Workflow --version 0.7.1
npx degit Tenon-Net/TenonAdmin/web#v0.7.1 webあとは上の 2 節に従ってください。段階ごとの実装記録、検証エビデンス、消費者としてハマった点の一覧はすべて docs/ にあります。