完了成果 47

SORA再現

#55 SORA_WF_LOT_MGMT（出荷船積みロット決定）ワークフロー検証
  • `02_Areas/workflows/WF_LOT_MGMT.md` を新規作成
  • 出荷船積みのロット決定プロセスを11ステップで定義
  • フロー: 本船別進捗確認 → LOT FIXED実行 → 船積NG確認 → 引当解除 → 揚込 → ロット完了通知 → 帳票DL
  • アクター: SCM船積み担当者 / SCM承認者 / システム
  • 対象画面: SRL1SC2202, SRL1SC2602, SRL1SC2603, SRL1SC2604, SRL1SC2605
 Done km198109
#65 ロット決定フロー機能の検索ロジック精査と処理組み込み
  • CLOSE後の追加対応として、SRL1SC2604 を v7 (/change + /sync) ラインで本格実装しました。SRL1SC2202 で確立した修正パターンを横展開し、API 統合まで完了しています。
  • | # | Delta | 内容 |
  • |---|---|---|
  • | D-001 | sc2604_section_c_renumber | セクションC 項目ID 衝突解消 (D-1..D-11 → C-1..C-12) + Vessel名(C-7) 追加 |
 Done km198109
#64 ロット決定フロー関連項目の精査
  • 精査スコープ 4 項目中 3 項目完了 (関連 workflow.md / view.md / api.md・entity.md の項目確認)。残 1 項目 (精査結果のまとめ / フォローアップ Issue 起票) は v9 化で自然発生する別 Issue に継承。
  • v7 → v9 への全面移行 (md 11 本、Round 3 段) に伴い、本 Issue は close。再起票は行わない。
  • Refs: #55
 Done km198109
#62 [検証] SRL1SC1007_MP を題材とした SORA でのチャート実装方式の検証
  • | カテゴリ | 内容 |
  • |---|---|
  • | 画面仕様書 | `02_Areas/views/SRL1SC1007_MP.md` 新規作成 (セクションA/B、26 項目、イベント 2 本) |
  • | 親画面側更新 | `02_Areas/views/SRL1SC1007.md` セクションF 削除 + A-41 イベント遷移先を SRL1SC1007_MP に更新 |
  • | デザイントークン | DESIGN.md §2 に「Chart Colors」サブセクション追加、common.css に 6 変数追記 |
 Done junior-portx (作成者)
#71 ロット決定フロー機能の検索後の各種ロジック精査と処理組み込み
  • ロット決定フロー検索後の各種ロジック精査は、#65 と同スコープ (SRL1SC2202/2203/2604 + 2605 等)。v9 化 (workflow.md v9 + logic.md の Command 再設計) で再整理。
  • 再起票は行わない。
  • Refs: #55
 Done km198109
#73 ロット決定実行に関連する各種ロジック精査と処理組み込み
  • #73 AC の SRL1SC2605 未対応分について、SRL1SC2604 (`0ac54a0`) で確立した実装パターンを横展開しました。Sync（migration 適用 / Edge Function デプロイ / main 反映）は別途実施予定。
  • | 分類 | ファイル | 状態 |
  • |------|--------|------|
  • | API | `02_Areas/apis/AC_SRL1AC0099.md` | 新規（ロット完了通知 初期表示 フル仕様） |
 Done km198109
#72 ロット決定実行に関連する各種ロジック精査と処理組み込み
  • ロット決定実行関連 (SRL1SC2601〜2605 の各種ロジック) は未着手、v9 化 (workflow.md v9 + logic.md + rules.md + errors.md の HOW 層分解) で再スコープ。
  • v7 時代の画面単位 task 粒度は、v9 では Command 単位 (logic.md .commands[]) + Saga 単位に再構成される。
  • 再起票は行わない。
 Done km198109
#74 ユーザーとWorkFlow検討に入る際の初回議論方法の確定
  • 本 Issue と #70 は Formula を挟んで前後関係になる別タスク。混同しないように範囲を明記する。
  • | Issue | スコープ | 位置づけ |
  • |---|---|---|
  • | #74（本Issue） | Formula への最初のINPUT（外の世界の成果物） | Formula に投入される前の上流成果物。顧客と最初に議論する叩き台そのものの形式・プロセス・ツール |
  • | #70 | Formula としての成果物定義 | Formula パイプライン内部で生成する deliverables（workflow.md / view.md / api.md など） |
 Done km198109

Formula 仕様

#20 期間管理（終了日自動計算）の共通パターンを Domain/Common.fs に追加する
  • 最低保険料の終了日自動計算（次レコードの開始日-1日、最終=9999/12/31）は保険料率マスタでも同様のロジックが必要。
 Done kuma-portx (作成者)
#19 DateTime vs DateTimeOffset の統一方針を BACKEND_DESIGN.md に明記する
  • lot PoC では全日付フィールドに DateTimeOffset を使用。保険料率 walkthrough では日付は DateTime、タイムスタンプは DateTimeOffset と使い分け。
 Done kuma-portx (作成者)
#17 ステータス動的計算 (source: computed) の view.md/sync 対応
  • 最低保険料の4値ステータス（有効/期限切れ/適用予定/未設定）はDB カラムではなくクライアント側で動的計算する値。
 Done kuma-portx (作成者)
#14 api.md にエラーレスポンス定義セクションを追加する
  • FE の api.md にはエラーレスポンス定義がない。BE は DomainError → ErrorMapping で構造化されたエラーを返すが、FE はそのフォーマットを知らない。
 Done kuma-portx (作成者)
#11 DomainError DU をドメイン別に分離してスケーラビリティを確保する
  • lot PoC の DomainError DU (9ケース) に minimum_premium を追加すると +7ケース = 16ケース。ドメイン追加ごとに線形肥大化。
 Done kuma-portx (作成者)
#10 workflow.md テンプレートを v5 → v6 に拡張する
  • workflow.md テンプレート (`02_Areas/templates/workflow.md`) が v5 のまま。v6 の concepts / states / rules / errors / asis_sources セクションが未定義。
 Done kuma-portx (作成者)
#8 api.md を FE/BE の統一契約書として確立する
  • Pipeline v2 E2E シミュレーション（最低保険料管理 SRL1SC2814/2815）で発見された CRITICAL 問題。
 Done kuma-portx (作成者)
#67 自動で組込む画面の動きの精査
  • Issue 完了条件「他プロジェクトで活用可能なMD記載（暫定版で良い）」について、ガイドMDを作成しました。
  • `02_Areas/guides/common-screen-behaviors.md` — 画面共通挙動カタログ
  • 1. 初版作成 — #64 / #65 / #73 対応（#75 / #76 PR）で確立したパターン + 既存 view.md 横展開 + 一般論ベストプラクティスを 3 視点タグでピックアップ
 Done km198109
#70 WolkFlow整理段における顧客側の理解促進を助ける成果物の検討
  • 本 Issue と #74 は Formula を挟んで前後関係になる別タスク。混同しないように範囲を明記する。
  • | Issue | スコープ | 位置づけ |
  • |---|---|---|
  • | #70（本Issue） | Formula としての成果物定義 | Formula パイプライン内部で生成する deliverables（例: workflow.md / view.md / api.md など、顧客と Formula の間で出力される成果物） |
 Done km198109
#78 [v9-spec] md 構成 spec 追記 + template 整備 (F-01..F-20 の md 層 15 件)
  • commit `c2d749d` で実装完了。
  • 26 files changed, +1,590 / -194 行
  • v9-synthesis.md §6 新設 (+417 行、15 件原則)
  • batch.md template 新設 (F-16)
  • 10 templates 更新 (F-01..F-20 反映)
  • WF_SRL1_INBOUND_OUTBOUND 回帰適用
  • WF_DP_LIST 検証適用
 Done kuma-portx (作成者)
#81 [v9-flow] Round/Phase 運用ルール整理 (F-23..F-27)
  • commit \`096b52d\` で実装完了。
  • 2 files, +736 行
  • \`04_Archives/reports/2026-04-22_v9-synthesis.md\` §7 新設 (+240 行)
  • \`03_Resources/ops/round-playbook.md\` 新設 (496 行)
  • | F-NN | §7 解決 | playbook 具象 |
  • |---|---|---|
 Done kuma-portx (作成者)

Formula パイプライン

#21 /evidence にバックエンドテスト（dotnet test）統合を追加する
  • 現在の /evidence スキルは FE のみ（Svelte + Edge Function + DB + スクリーンショット）。F# バックエンドのテスト結果が含まれない。
 Done kuma-portx (作成者)
#18 ESRL1A0019 の多義性を解消する（1コード2状況問題）
  • AS-IS エラーコード ESRL1A0019 が「損保会社コード不在」と「items[] 内部重複」の2つの状況で使用される。
 Done kuma-portx (作成者)
#16 楽観ロックの自動生成パターンを確立する (FE/BE)
  • 楽観ロック（rec_upd_tmstmp による排他制御）は最低保険料に限らず多くのマスタメンテ画面で必要だが、自動生成パターンがない。
 Done kuma-portx (作成者)
#15 モーダル画面の生成パターンを /sync に追加する
  • SRL1SC2815（最低保険料明細照会）のようなモーダル画面の生成パターンが /sync にない。
 Done kuma-portx (作成者)
#13 entity.md の自動生成機能を /generate に追加する
  • workflow.md v6 の concepts セクションに table 参照やフィールド定義が含まれているが、entity.md は手動作成のまま。
 Done kuma-portx (作成者)
#12 /generate で workflow.md v6 ドメインセクションを活用する
  • /generate は workflow.md の screens セクションから view.md を生成するが、v6 の concepts / states / rules / errors を活用していない。
 Done kuma-portx (作成者)
#9 /discover スキルを実装する
  • Pipeline v2 の Phase A（Domain Discovery）を自動化する `/discover` スキルが未実装。
 Done kuma-portx (作成者)
#30 workflow 合意フェーズで DDD 議論を成立させる — viewer 進化 + RFP 統合
7 / 7
100%
  • workflow 合意フェーズでの DDD 議論は、今日 v9 確定 (2026-04-22) で以下のように完了:
  • 3 specialist (Scott DDD / Palantir Action / Clean Architecture) 並列議論で統合 (`04_Archives/reports/2026-04-22_v9-synthesis.md`)
  • workflow.md v9 を Saga / Use Case Scenario 専用に、logic.md に Command / Domain Event / Saga を独立させ、DDD 原則 (Aggregate boundary / Domain Event-first / illegal states unrepresentable) を md 層に適用
 Done kuma-portx
#50 /rfp 撤回、/discover を WHY+WHAT 統合ハブに (#35 方針転換)
  • しかし運用方針として 「AsIs を調査してドメインに落とす部分は基本 discover」「discover = 要件定義メインハブ」 に一本化。`/rfp` スキル新設は撤回し、WHY (goals / RFP) と WHAT (concepts / states / rules / err…
 Done kuma-portx (作成者)
#65 [検証] Project 管理整備の動作確認
  • 2026-04-20 の Project 管理整備一連の動作検証用 Issue。
 Done rei-okawara-portx
#53 [検証] formula-sora での /issue 動作確認
  • cross-repo の動作検証用 Issue。
 Done rei-okawara-portx
#55 [Formula v9] 仕様統合 Pipeline (md 11 本 / Round 3 段 / α 案 skill / Viewer 5 コア)
8 / 8
100%
  • Round 2 dogfood (2026-04-22) で v9 pipeline を SORA 出荷船積ドメインに適用、27 件の framework 問題を検出。T1-T4 (#78 / #79 / #80 / #81) で全解消完了。
  • | 当初 scope | 達成 |
  • |---|---|
  • | md 11 本 (WHY 3 + HOW 4 + Domain 3 + Adapter 3) | ✅ templates 全 11 本整備 (batch.md 新設含む) |
 Done kuma-portx (作成者)
#63 [v7-spec] logic スキーマに permissions / side_effects / submission_criteria を追加
  • Task #56 実証 + Final v3 議論で本 Issue の 3 フィールドは workflow.md v8 の logic 配下に統合確定、新規 skill 不要 (α 案)。
  • 確定した配置:
  • `permissions` → logic SSOT (英語キー + 業務日本語見出し)
  • `side_effects` → flow step SSOT
  • `submission_criteria` → logic SSOT
 Done kuma-portx
#79 [v9-skill] 既存 skill の v9 化 + contract 概念正式化 (F-07, F-13)
  • 別 worktree \`claude/busy-chebyshev-4e6c10\` で T2 が完了:
  • \`017e7e1 feat(skills): T2 MVP — /discover + /change を v9 対応化\`
  • \`3c03e23 feat(skills): T2 後続 — /verify-workflow, /workflow, /generate, /sync を v9 対応化\`
 Done kuma-portx (作成者)
#80 [v9-viewer] Viewer の 11 md 対応 + cross-WF (F-09, F-11, F-21, F-22)
  • commit `676da2c` で実装完了。
  • \`_system/workflow-viewer.html\`: +231 / -3 行
  • screenshots/phase-3/t3-verification/ に 3 WF × 3 タブ = 9 スクショ
  • F-09 (11 md 対応): FILES 配列に entity/view/api/batch 追加、V_E (Entity Browser) + V_A (Adapter) タブ新設
 Done kuma-portx (作成者)

デプロイ環境構築

#41 upstream-sync workflow が PAT 未登録で稼働不能 — Expecto 再発防止策の修復
  • `.github/workflows/upstream-sync.yml`（#38 で追加）が、スケジュール実行・手動 dispatch とも以下で失敗し続けている:
 Done kuma-portx (作成者)
#44 upstream sync を cron 自動から PR CI チェックに切替
  • - 常時追従は不要、案件都合で upstream を固定したい瞬間 もある
 Done kuma-portx (作成者)
#47 .gitattributes の ours 指定漏れ解消 — 新規 branch push の pre-push hook block を恒久対処
  • PR #42/#43/#45 の作業中、pre-push hook が以下のファイル群を SHARED (merge=ours 未指定) かつ upstream/main と不一致 (DIVERGED) と判定して新規 branch の push を block する事象が発生。今回は既存 t…
 Done kuma-portx (作成者)

デザインシステム

#56 DESIGN.md ↔ common.css クラス名不整合の解消
  • DESIGN.md / SKILL.md で言及されているクラス名が common.css に未実装、またはその逆のケースが多数存在する。
 Done junior-portx (作成者)
#57 DESIGN.md / common.css / SKILL.md リファクタリング
  • DESIGN.md / common.css / SKILL.md の3ファイル間に30+のクラス名不整合・用語の矛盾・曖昧な仕様が存在し、画面生成時にミスが多発していた。
  • 本対応で:
  • 3ファイルの SSOT 依存方向を確立（DESIGN.md → common.css → SKILL.md）
  • DESIGN.md をロール分類 + コンポーネント統合形式に再構成
  • SKILL.md から存在しないクラス30+を削除し common.css 実体に整合
 Done junior-portx (作成者)
#60 【SORA】DESIGN.md にグラフ/チャートのデザイン定義を追加
  • DESIGN.md へのチャート定義追加と、SRL1SC1007 MP在庫シミュレーション画面での試験実装を実施。月曜 (2026-04-20) に方針決定予定。
  • デモサイト (`https://sorastep4-demo.com/mp-inventory-simulation?targetMonth=2026-04`) を chrome-devtools MCP で分析
  • SRL1SC1007 の A-41 ボタン押下は `window.open('/mp-inventory-simulation?targetMonth=YYYY-MM', 'mpInventorySimulation', '1200x800')` で popup 起動
 Done junior-portx (作成者)
#54 Claude Design（Anthropic 新ツール）による DESIGN.md / common.css 生成検証
  • 本タスクの作業目的: 画像 / 自然言語から DESIGN.md を生成する こと
  • Claude Design の本質的な強み: 雑な指示や雑なポンチ絵から簡易サイトを形にする こと（ゼロ → 形あるもの）
  • 今回の DESIGN.md 生成は 既存 Figma / スクショ → 構造化 Markdown であり、Claude Design の強みが活かされない使い方になっていた
  • 既存デザイン（Figma / スクショ）を読み込んで DESIGN.md を生成する流れは、Claude Code でも Claude Design でも プロンプトへの記入 / 情報整理 でほぼ等価。差別化要素が見当たらない。
 Done junior-portx

レポート

#51 [report]spec.md に Action を一級要素として導入する
  • Palantir Foundry/Ontology/AIP と Formula の技術比較レポート（2026-04-14）において、両者が「業務の正本(SSOT)を1箇所に持ち、そこから全てを自動派生させる」という同型の思想を持つことが確認された。
 In Progress rei-okawara-portx
#69 調査: Formula 方法論と類似ツールの構造比較（BMAD-METHOD v6 主軸・Spec Kit / Kiro / Tessl / Palantir Ontology）
  • 2026-04-21 に formula-sora でアーカイブされた `2026-04-21_formula-spec-final.html`（Formula 仕様統合 Final v3）で示した「8 MD SSOT × agent team × 5コア Viewer」構成に対して、既存の類…
 In Progress rei-okawara-portx
#73 [Report] MD → Runtime Platform 構想と Hybrid 推奨（OPA + JSONLogic）
  • 記録完了。実行に移す際は新規 Issue を起こし本 Issue を参照すること。
 Done rei-okawara-portx (作成者)
#74 [Report] Tailor (jp.tailor.tech) 比較 — Formula との類似点と取り込むべき改善点
  • docs.tailor.tech/guides/ の公式ドキュメントを参照し、Tailor Platform の 実像 をベースに Formula との比較を再構成する（初版は marketing site ベースで、Tailor を「クローズド SaaS」と誤認していた）。
 Done rei-okawara-portx (作成者)
#75 BMAD-METHOD v6 採用検討 — Formula authoring パイプライン代替の可否
  • docs.bmad-method.org の公式ドキュメントを精読し、BMAD-METHOD v6 を 5 Agent + 4 Phase + 25 Skill + 8 高度機能 の構造で徹底分解。Formula との詳細比較を実施し、取り込むべき具体的観点を 8 項目 に整理した。
 In Progress rei-okawara-portx (作成者)
#79 検証: Directus + 独自 Svelte UI で Formula-sora 再現 — 90% 再現、L1-L3 分類付き
  • 整理された提案版として #80 を起票しました。検証プロセスの詳細履歴は本 Issue に残しますが、採用判断は #80 で続けます。
 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