完了成果 9

SORA再現

#27 SORAの設計書をインプットとしてFormulaで再現する
  • https://formula-prototype.pages.dev/sora
  • 2026-04-13〜04-14 にかけて Phase 1〜6 を完了。
  • entity.md: 22件 / view.md: 42件 / api.md: 105件 / workflow.md: 6件
  • Svelte画面: 42件（29画面 Server Route 接続済み）
  • SvelteKit Server Route: 28本
 Done rei-okawara-portx

共通基盤

#31 認証基盤の検証（Supabase Auth / Logto / 他）
  • E2Eテストにより Supabase Auth + RBAC + OU制御の動作を検証完了。認証基盤は Supabase Auth に決定。
 Done rei-okawara-portx

Formula パイプライン

#47 README にマネジメントフローセクションを追加
  • PR #48 で確立した 3 スキル体制 + Status 5 値 + PR 連動の運用フローを、main の README.md からすぐに把握できるようにする。
 Done rei-okawara-portx (作成者)
#26 Project メソッドから GitHub Issue への移行（ダッシュボード/Wiki 整備）
  • \`01_Projects/\` 配下の PARA 的タスク管理（Epic / Container / Task / Question / Handover）を廃止し、GitHub Issue + GitHub Projects に正式移行する。ドキュメントは本体 repo の Markdow…
 Done kuma-portx

デプロイ環境構築

#22 案件単位で Cloudflare Pages + Supabase 環境構築 & CI/CD 連動
  • 案件リポジトリごとに Cloudflare Pages + Supabase の構成でデプロイ環境を構築しました。
  • フロントエンド: Cloudflare Pages（案件名 = Pages プロジェクト名）
  • バックエンド/DB: Supabase（案件ごとにプロジェクトを作成、東京リージョン）
  • CI/CD: GitHub Actions で `main` ブランチへの push に連動して自動デプロイ
 Done rei-okawara-portx
#21 リポジトリのアップストリーム/ダウンストリーム整理
  • 案件横断で共通の設計資産（スキル・スクリプト・テンプレート・型定義）を Upstream Repo に集約し、各案件 Repo は Fork + upstream 同期で追従する構成に整理する。
 Done kuma-portx
#2 Edge Functions: esm.sh 外部依存を npm specifier に移行
  • Edge Functions の `@supabase/supabase-js` import を `https://esm.sh/` 経由から `npm:` specifier（import_map.json）に移行する。
 Done rei-okawara-portx (作成者)
#2 Edge Functions: esm.sh 外部依存を npm specifier に移行
  • Edge Functions の `@supabase/supabase-js` import を `https://esm.sh/` 経由から `npm:` specifier（import_map.json）に移行する。
 Done rei-okawara-portx (作成者)

ユースケース検証

#29 PRD プロトタイプ版 検討事項（チーム相談）
  • PRD プロトタイプ版（v0.2）の検討事項をチームで議論したい。
 Done rei-okawara-portx

進行中 6

共通基盤

#77 認証認可基盤のアーキテクチャ検討
  • Formulaにおける認証認可基盤の実装に向けて、アーキテクチャ検討や実装を進める。
 In Progress yu-tomori (作成者)
#30 共通基盤（ログイン/ユーザー管理/ロール管理）を /sync で生成するか
  • PRD プロトタイプ版（v0.2）の検討事項のうち、共通基盤の生成方針について議論したい。
 In Progress yu-tomori, kuma-portx
#28 共通基盤の仕様MD作成（ログイン/ユーザー管理/ロール管理）
  • パイプライン外の共通基盤（全案件共通）として、認証・認可に関する画面の仕様MDを作成する。
 In Progress yu-tomori, kuma-portx
#49 テンプレートMD作成（LOGIN/USER_MGMT/ROLE_MGMT/PERM_MGMT/OU_MGMT）
  • /sync で認証・認可画面を生成するためのテンプレートMDを作成する。
 In Progress yu-tomori, kuma-portx

ユースケース検証

#24 不二製油さんをformulaで再現する
  • 不二製油さんをformulaで再現する
 In Progress km198109

レポート

#76 [Report] Tailor Platform 徹底分析 — Formula 取り込み観点 12 項目
  • # 🎯 SaaS 標準 vs カスタマイズ — 3 層モデルで整理
  • Tailor をどこまで「そのまま使える」状態で済ませられ、どこから「作り込み」になるかを 3 つの層 で整理する。
  • | 層 | ひとこと | 書く量 | スキル要件 |
  • |---|---|---|---|
  • | 🟢 L1 | そのまま使える機能 | ゼロ | 不要 |
  • | 🟡 L2 | 条件を書けば動く領域 | 設計書レベル | 業務理解＋コード基礎 |
 In Progress rei-okawara-portx (作成者)

直近のタスク予定 26

共通基盤

#50 sync で認証・認可画面を生成する（ログイン/ユーザー管理/ロール管理/権限管理/組織管理）
  • テンプレートMD（LOGIN/USER_MGMT/ROLE_MGMT/PERM_MGMT/OU_MGMT）を入力として、/sync で認証・認可画面（.svelte）を生成する。
 Todo yu-tomori, kuma-portx
#53 操作ログ・ログインログ機能の実装
  • ユーザーの操作ログ（画面操作・データ変更等）およびログインログ（認証イベント）を記録・管理する機能を実装する。
 Todo yu-tomori
#66 menu システムの統合方針検討（menu.md vs view.md props vs ハイブリッド）
  • Formula のパイプライン (workflow.md → view.md → api.md → entity.md) に menu（ナビゲーションメニュー）の管理 を組み込みたい。
 Todo yu-tomori

Formula 仕様

#16 業務シナリオ入力フォーマットの標準化
  • workflow.mdを生成する際のインプット（業務シナリオ）のフォーマットが未定義。FDEのスキルレベルによって出力品質にブレが生じる。
 Todo km198109
#37 batch.md（処理機能記述）のフォーマット設計
  • バッチ処理・非同期処理の仕様を定義する batch.md のフォーマットを設計する。SORA の処理機能記述書（IPO: WP0031）をFormula形式に変換するためのMD仕様。
 Todo kuma-portx

Formula パイプライン

#1 コード管理と活用（区分値・マスタの共通管理方法）
  • マスタで管理するコード、区分値の管理等、システムで共通的に再利用される値の共通管理方法と各機能で活用する際の表現方法を組込む必要がある。
 Todo kuma-portx
#2 機能一覧の自動生成（成果物としても提供可能な一覧）
  • 成果物としても提供可能な機能一覧を自動で起こす仕組みが欲しい。
 Todo kuma-portx
#3 帳票機能（帳票定義MDと帳票生成の仕組み）
  • 帳票機能と帳票を定義するMDがほしい。
 Todo kuma-portx
#4 スケジュール実行機能（バッチのスケジュール管理）
  • バッチのスケジュール実行を管理する機能。
 Todo kuma-portx
#5 残課題管理（Agent生成時の残課題を適切に管理する機構）
  • フロー作成等をagentで実施すると、残課題をあげてくれる。これを適切に管理していく機構を設けたい。
 Todo kuma-portx
#13 spec MD（view.md）→ workflow.md の双方向同期
  • view.mdを修正した場合にworkflow.mdへ反映する仕組みがない。現状は上流（workflow.md）→下流（view.md）の一方向のみ。
 Todo kuma-portx
#14 ワークフローMD再生成時の既存view.md保護
  • ワークフローMDに機能追加が発生し再ジェネレートした場合、既存のview.mdが上書き・消失するリスクがある。
 Todo km198109
#15 change コマンドの改善（手動編集の自動検出）
  • view.mdを手動編集した後に毎回 /change を叩く運用は煩雑。手動編集の変更点を自動検出する仕組みが必要。
 Todo kuma-portx
#18 コード管理（区分値・マスター）のルール策定
  • ステータス等の区分値やマスターデータの管理方法のルールが未整備。共通的に使うコードの管理ルールをview.mdに定義する必要がある。
 Todo km198109
#20 To-Be業務フロー設計のプロセス・フォーマット整備
  • 上流のTo-Be業務フロー設計のフォーマットやプロセスが未整備。FDEの質によるアウトプットのブレを減らす必要がある。
 Todo km198109
#23 選択肢やコード管理の検討
  • 選択肢やコード管理の検討
 Todo km198109
#85 [v9-skill] /verify skill 新設 + /verify-workflow 廃止 (整合性検証の scope 拡張)
  • Issue #82 で /change / /sync / /build の責務再設計を進める中、user が `/verify-workflow` の 名前と scope の狭さ を指摘:
 Todo kuma-portx (作成者)

デプロイ環境構築

#33 プロトタイプ → 本番の移行戦略
  • PRD プロトタイプ版（v0.2）の検討事項のうち、プロトタイプから本番への移行戦略について議論したい。
 Todo kuma-portx
#67 プロト→本番 移行戦略 再検討 (Supabase 廃止・F#/Cloud Run/Cloud SQL 前提)
  • 本 Issue スコープ (BE 側) と yu-tomori スコープ (IdP 選定) の境界を明確化し、検討内容を記録する。
  • F# BE のミドルウェア構造は以下 (既存 `backend/src/Formula.Api/Program.fs` より):
  • ┌─────────────────────────────────┐
  • │ Giraffe (F# 関数ルーティング) │ ← webApp: HttpHandler
 Todo rei-okawara-portx
#80 提案: Directus + 独自 UI を Formula deploy target に採用 (整理版)
  • Directus (OSS) + 独自 Svelte UI を Formula の deploy target として採用推奨。
 Todo rei-okawara-portx (作成者)

ユースケース検証

#71 StoriesOnBoard 出力の Formula USER_STORY.md 取込検証と PoC 計画
  • Issue #69 の方法論比較で、Formula の WHY 層（USER_STORY.md） を半自動化する候補として StoriesOnBoard が浮上した。
 Todo rei-okawara-portx (作成者)
#78 検証: NocoBase で Formula-sora (SRL1) 再現 PoC — 約65%再現可能、PortX クラウド deploy target 候補
  • browser-use 相当の Playwright 操作で Table block 追加まで成功。データ 5 件認識。残りの column 設定は UI の中間 menu 構造が特殊で click-through 途切れたため、UI エディタで 30 秒の手動操作で完了可能。
  • !add-block-menu
  • `08-add-block-menu.png` : Add block → Data blocks → Table の submenu に Collection 一覧が表示（例外出荷 / 納車先 / 承認リクエスト + 標準 Roles/Users）
 Todo rei-okawara-portx (作成者)

デザインシステム

#68 CSS 基盤 (Tailwind) と Formula 外配布ポリシーの方針検討
  • Issue 本文の Topic 1/2 の方針議論と並行して、「そもそも DESIGN.md + common.css で再現性ある画面を作れるのか」の実測エビデンスを追加します。
  • YES、ただし再現されるのは「デザイン側面」のみ。「データ・命名・粒度」の再現には別の仕組みが要る。
  • | 観点 | 一致率 | コメント |
  • |-----|--------|---------|
  • | App Shell / カラー / chip / レイアウト | 100% | context なしでも 90%+ |
 Todo rei-okawara-portx

レポート

#70 [Report] Augment Code (Intent) 評価 — Formula tooling 代替候補として
  • 結論: Augment Code の `Intent` は、これまで調査した OSS / 有料ツールの中で Formula の core orchestration layer（agent team + `/change` → `/sync` + reviewer + `/evidence`）…
 Todo rei-okawara-portx (作成者)

(Epic 未設定)

#84 Fuji の DESIGN.md のベストプラクティス調査
  • 別案件 Fuji の DESIGN.md を参照し、SORA の DESIGN.md に取り込むべきベストプラクティスを抽出する。
 Todo junior-portx (作成者)
#83 検索補助画面の DESIGN.md と画面作成 (新 modal 方式)
  • 検索補助モーダルのデザイン定義 (DESIGN.md) と画面実装 (SRL1SC9016.svelte) を新しい in-page modal 方式で作成する。
 Todo junior-portx (作成者)

Auto-generated 2026-04-23 | GitHub Projects | Portal