- この
TODO.mdは Java 版 CLI 中心の移植計画を扱う - ここでは「今後の判断」や「完了条件」を優先して残し、個々の確認結果や通過ログの正本は
docs/remaining-migration-items.mdに寄せる vendor/mikuproject/docs/TODO.mdは upstream 機能差分、仕様制約、入出力の未整理事項を扱う
- 新規機能追加ではなく、既存実装の確認、TODO / docs 整理、移植済み範囲の検証や差分確認に限定して進める
docs/remaining-migration-items.md,docs/upstream-class-mapping.md,docs/upstream-test-mapping.md,docs/upstream-followup-log.mdの整合を保つ- 既存 command / API / fixture 回帰の不足が見つかった場合は、機能追加ではなく既存仕様の不足またはバグとして扱う
- 再開ポイント:
- ここまでで
dependency.xmlの report directory / report bundle ZIP / monthly SVG ZIP は Node upstream と byte-level parity 済み - ここまでで WBS XLSX / SVG / report ZIP 系の大きな簡略化は潰し、
mvn packageと opt-in Node parity が通っている ProjectXlsxExport*の editable cell styling、sheet theme、Project sheet の Settings section / merged range は upstream TypeScript と照合して Java 側へ反映済みprojectpatchjsonの warning / blocker details はdelete_task,delete_resource,delete_calendar,delete_assignmentを upstream と構造比較し、Java 側へdelete_assignmentを反映済み- 次に再開するなら、Agent Skills 側の
project_draft_view生成契約確認、または zero duration task warning 方針の整理へ進む
- ここまでで
- 残作業を新規機能追加ではなく、既存範囲の確認 / docs 整理 / upstream 差分確認へ絞る
-
README.md,docs/remaining-migration-items.md,docs/upstream-class-mapping.md,docs/upstream-followup-log.md,docs/msprojectxml-import-design.mdの現在フェーズ表現を揃える - Agent Skills 側で
project_draft_view生成時にplanned_start/planned_finishを入れる前提になっているか確認するmikuproject-skills紹介記事や upstream sample ではplanned_start/planned_finishを含む例があるが、現時点で task ごとの日付を必須とする契約までは固定されていない- upstream
msproject-ai-views.tsと JavaMsProjectAiViewsはどちらも task 日付未指定を許容し、project.planned_startまたはproject.planned_finishを起点に import する - そのため 2泊3日など期間を持つ計画でも Agent Skills 側が task 日付を落とすと、全 task が同一日時 / zero duration に寄り得る。Java 側で自動補完する話とは分けて、warning 方針の論点として残す
- mikuproject-java 側で zero duration task が大量に来たときの warning 方針を検討する
- 方針は import 導線ごとの個別 warning ではなく、共通
ProjectModelvalidation warning として扱う - 現時点では
validate-xml/validateProjectModel(...)で、placeholder / summary / milestone を除く複数 task が同一start/finishかつ zero duration に潰れている場合に warning を返す - workbook JSON / AI JSON / XML import 自体の戻り warning へ混ぜるのは見送り、既存の validation 導線と runtime docs に揃える
- 方針は import 導線ごとの個別 warning ではなく、共通
- Node 版に比べて Java 版の straight conversion が薄い箇所を解消する
- 優先度 A:
excelio/XlsxWorkbookCodec-
exportWorkbook(...)が実 Excel OOXML zip ではなく独自mikuproject_xlsx_workbook_v1形式を返している問題を修正し、主要導線を OOXML ZIP へ切り替える -
exportWorkbookArchive(...)/importWorkbookArchive(...)は report / CLI / Core API の主要導線から使う形へ寄せた - upstream の
dataValidationsと style descriptor の主要部を Java 側の OOXML build / parse に反映する -
formula,freezePaneを Java 側 model / OOXML build / parse に反映する
-
- 優先度 A:
projectxlsx-
ProjectXlsxExport*の列幅、boolean data validation、boolean option sheet を upstream 寄りに補強する -
ProjectXlsxExport*の editable cell styling、sheet theme、Project sheet の Settings section / merged range を upstream 寄りに補強する - import 側も upstream の workbook validation / editable cell 前提とズレがないか、fixture round-trip と sheet 構造で確認する
-
- 優先度 A:
wbsxlsx- WBS workbook の主要導線が独自 workbook bytes を出しており、
wbs.xlsxというファイル名と実体が合っていない問題を修正する - upstream 相当の row height、hidden columns、style、date band cell、progress band、summary / legend へ寄せる
-
dependency.xmlの Node parity でwbs.xlsxの OOXML ZIP / worksheet XML / styles XML / workbook XML が byte-level 一致するところまで寄せる freeze/formulaは Java 側 model / OOXML build / parse へ反映済み。WBS workbook 自体は現時点でこれらを使っていない
- WBS workbook の主要導線が独自 workbook bytes を出しており、
- 優先度 B:
wbssvg-
dependency.xmlの Node parity でdaily.svg/weekly.svg/monthly-calendar/*.svgが byte-level 一致するところまで寄せる - 週次 SVG は viewport trim / label placement / dependency connector routing の主要部を Java 側へ反映済み
- daily / weekly / monthly について、見た目の目視だけでなく class / shape / path 構造比較テストを追加する
-
- 優先度 B:
projectpatchjson-
first cut制限自体は upstream 由来だが、Java 側の warning 詳細や参照 blocker が薄くなりやすい箇所を確認する -
delete_task,delete_resource,delete_calendar,delete_assignmentの warning / changes を upstream と構造比較する
-
- 優先度 C: docs / follow-up log
-
docs/upstream-followup-log.mdの「大きな差分は見当たらない」という過去記録を、今回見つかった薄い箇所で更新する -
docs/remaining-migration-items.mdの CLI/report 完了率表現を、XLSX / SVG の再点検が終わるまで保守的に戻す
-
- 優先度 A:
- 同一入力に対する Node 版 / Java 版の全出力 byte-level parity 方針を決め、比較テストへ分解する
- 方針: straight conversion の検証軸として、CLI / Core API が返す「出力という出力」は原則 Node 版 upstream とバイト一致を目標に置く。ただし現フェーズでは report 系出力を優先して parity を固定し、JSON view / XML / diagnostics / project XLSX など非 report 全出力への拡張は次段の保守対象として明示的に切り分ける
- 対象 A: report 派生出力の
wbs.md,mermaid.mmd,daily.svg,weekly.svg,monthly-calendar/*.svg,wbs.xlsx, report bundle ZIP, report directory - 対象 B: workbook / project 交換出力の workbook JSON, project overview view JSON, phase detail view JSON, task edit view JSON, project draft request JSON, exported XML, project XLSX
- 対象 C: validation / detection / import / merge 系の stdout text / JSON diagnostics / generated XML / generated workbook bytes
- 前提:
svg,md,mmd, JSON, XML のような plain text 生成物は、同じ model / options / key order / 改行規約 / UTF-8 encoding でバイト一致を目標にできる - 前提:
.xlsx/ report bundle / monthly SVG ZIP も、entry 順、entry 名、entry bytes、ZIP local header / central directory / CRC32 / 圧縮方式 / timestamp を upstream と揃えればバイト一致を目標にできる - upstream 確認:
main-util.tsの report bundle ZIP とwbs-svg.ts/wbs-svg-zip.tsの monthly SVG ZIP は DOS timestamp を2025-01-01 00:00:00相当に固定している - upstream 確認:
excel-io-zip.tsの OOXML workbook ZIP は手書き ZIP だが mod time / mod date は0を書いており、report/monthly ZIP の2025-01-01固定とは異なる - Java 側の
ExcelIoZip.packZip,CoreApiReport.packZipEntries,WbsSvgZip.packMonthlyEntriesを deterministic stored ZIP writer に寄せ、report / monthly ZIP は2025-01-01 00:00:00、OOXML workbook ZIP は mod fields0を使う - 段階 1:
md/mmd/ standalone SVG / JSON view / XML など単体 text 出力を fixture ごとに Node 版出力とバイト比較する- 現時点では report 系 text 出力は
dependency.xmlの opt-in Node parity に含まれている。JSON view / XML / diagnostics まで広げるかは、現フェーズでは未着手のまま保留する
- 現時点では report 系 text 出力は
- 段階 2: ZIP を展開した entry-level parity として、report bundle / monthly SVG ZIP /
.xlsxの entry 名、entry 順、entry bytes を比較する- 現時点では report bundle / monthly SVG ZIP /
wbs.xlsxの report 系 parity を確認済みであり、project XLSX や非 report 出力全体への拡張は今後の保守対象として残す
- 現時点では report bundle / monthly SVG ZIP /
- 段階 3 の前提として Java 側に upstream と同じ stored ZIP writer を移植する
-
.xlsxの主要導線を独自mikuproject_xlsx_workbook_v1出力から OOXML ZIP 出力へ切り替える -
styles.xmlを固定 2 スタイルから upstream 相当の動的 style book 生成へ寄せる -
wbs.xlsxの worksheet model を upstream 相当の project info / task rows / legend / summary / progress band へ寄せる -
.xlsxの worksheet XML / styles XML / workbook XML の byte-level parity を entry 単位で確認する- 現状:
dependency.xmlの opt-in Node parity は report directory 出力一式で一致する
- 現状:
-
dependency.xmlの opt-in Node parity で report bundle ZIP / monthly SVG ZIP の byte-level parity を確認するCoreApiReportの bundle entry 順も upstream と同じwbs.xlsx,wbs.md,mermaid.mmd,daily.svg,weekly.svg,monthly-calendar/*.svgに揃える- Project XLSX 側の editable styling / sheet theme / Settings section などの workbook layout 差分は 2026-04-21 時点で補強済み
- parity が難しい場合の例外は、差分理由を固定値、entry 順、JSON key order、XML serialization、数値丸め、locale / timezone、CLI diagnostics のどれかへ分類し、正規化比較へ逃げる箇所を TODO ではなく明示的な仕様として記録する
- 2026-04-21 時点では report 系 parity を現フェーズの完了ラインとし、非 report 出力への拡張は
docs/remaining-migration-items.mdの保守論点として残す
- 2026-04-21 時点では report 系 parity を現フェーズの完了ラインとし、非 report 出力への拡張は
- report 生成物全体の品質を再点検する
- SVG の日付軸 / 月次カレンダーが簡略実装へ退化していたため、同じ report 系の XLSX / ZIP / directory export も信用しすぎない
-
dependency.xmlの report directory 出力で、SVG / XLSX / MD / MMD の Node 版 byte-level parity を確認する -
dependency.xmlの report bundle ZIP / monthly SVG ZIP 出力で Node 版 byte-level parity を確認する - SVG は既存 TypeScript 版に寄せ、title 位置、style class、bar / milestone / phase の形状、dependency connector、weekly meta、monthly calendar の見た目を構造比較する
export-report-dir,export-report-bundle,export-monthly-svg-zip,export-wbs-xlsxを同一 fixture で出力し、entry 名、0 バイト有無、主要シート / 主要セル / SVG 構造を確認する-
wbs.xlsxと standaloneexport-wbs-xlsxの内容が同等か確認する- 2026-04-21 時点で
MikuprojectCliTestに bundle / report dir / standalonewbs.xlsxの byte 一致確認を追加済み
- 2026-04-21 時点で
- report bundle zip と report dir の entry 構成が同等か確認する
- 2026-04-21 時点で
MikuprojectCliTestに entry 名と各 entry bytes の一致確認を追加済み
- 2026-04-21 時点で
- monthly calendar はプロジェクト期間に含まれる月がすべて出ること、各 SVG が空でないこと、zip 内 path が
monthly-calendar/YYYY-MM.svgになることを確認する- 2026-04-21 時点で
WbsSvgTestに sample / dependency / hierarchy の月数・file 名・非空確認を追加し、CLI 側では zip path をmonthly-calendar/YYYY-MM.svgで固定済み
- 2026-04-21 時点で
- dependency / hierarchy / 実利用サンプルの 3 系統で fixture を分け、サンプルだけで通る状態を避ける
- 2026-04-21 時点で monthly calendar の fixture coverage を sample / dependency / hierarchy に拡張済み
- upstream TypeScript 版との目視または構造比較が必要な項目を
docs/upstream-followup-log.mdへ記録する- 2026-04-21 時点で
core-api-report.tsとwbs-svg.tsの follow-up 記録へ、report 同等性回帰と monthly calendar の 3 系統 coverage を追記済み
- 2026-04-21 時点で
- XLSX / OOXML 系の簡略実装を upstream 相当へ戻す
-
CoreApiReportのwbs.xlsxentry とexport-wbs-xlsxがXlsxWorkbookCodec.exportWorkbook(...)の独自mikuproject_xlsx_workbook_v1形式を出しており、実 Excel workbook zip ではない問題を修正する -
XlsxWorkbookCodec.exportWorkbookArchive(...)/importWorkbookArchive(...)を report / CLI の主要導線から使う -
XlsxSheetLikeに upstream のfreezePane、XlsxCellLikeに upstream のformulaを追加する -
ExcelIoWorksheetBuildがdataValidationsを OOXML へ出していない問題を修正する -
ExcelIoWorksheetBuild/ parse がfreezePaneと formula cell を OOXML へ出し入れできるようにする -
ExcelIoStylesBuildが実際のfillColor/ alignment / number format / wrap / border の組み合わせを十分に反映せず、ほぼ固定 style へ潰している問題を修正する -
ProjectXlsxExport*は列幅、boolean data validation、boolean option sheet、editable cell styling、sheet theme、Project sheet の Settings section / merged range を補強済み - テストは byte size / decode だけでなく、zip entry、worksheet XML、styles XML、data validation、freeze pane、主要セル style を確認する
- 2026-04-21 時点で
ExcelIoTestが OOXML zip entry / worksheet XML / data validation / freeze pane / formula を確認し、ProjectXlsxTestが主要セル style、data validation、sheet theme、Settings section / merged range を確認済み
- 2026-04-21 時点で
-
- Java 版の対象を
CLI中心に固定し、対象範囲を文書で揃える-
README.md/docs/remaining-migration-items.md/TODO.mdで、Java 版の対象範囲をCLI中心に揃える -
対応済み保守確認の 2 区分で、現時点の領域分類を定義する -
straight conversionを原則とし、Java-first 再設計は後段で扱う方針を文書で固定する
-
- core / CLI / report の 3 系統で、移植計画を作る
- core 系について、upstream file 単位で
対応済み / 保守確認 / 保留を棚卸しする - CLI 系について、既存 command と upstream command/導線との差分を棚卸しする
- report 系について、
lossless 交換形式と人向け派生出力の役割を切り分けたうえで保守確認観点を棚卸しする
- core 系について、upstream file 単位で
- upstream 更新追随時の確認単位を、Java 側でも対応ファイル単位で辿れるようにする
- Node 版 upstream から継承する仕様と、Java 版でまだ保留の仕様を切り分ける
- Java CLI entry の役割を最小 entrypoint から全機能 entrypoint へ拡張する段取りを決める
-
null/ 未設定 / 空文字 /0の扱いを整理する - parse / import / validate 系のエラー返却方針を決める
- Node 側 options object を Java でどう表現するか決める
- package 依存方向とモジュール境界を整理する
- Java 側は過度な Java 流再編を避け、upstream のファイル境界を尊重して分割する
- upstream 1 ファイルに対して Java 側で複数クラスへ分ける場合も、追跡しやすい命名規則を決める
- Java 側の package 構成案を決める
- text / bytes / stream の I/O API 方針を決める
- 日付時刻の型とタイムゾーン方針を決める
- 数値型の方針を決める
- 文字コードを UTF-8 前提でどこまで明示するか決める
- upstream 比較を前提にしたテスト方針を決める
-
src/test/java/を用意する - JUnit Jupiter を Maven に追加する
- upstream 対応を意識したテスト class 命名規則を決める
- upstream の主要テストと Java 側テストの対応表を作る
- upstream fixture 比較を、core / workbook / report へ段階拡張する
-
README.mdに Java 版の目的を追記する - upstream 対応方針を
README.mdに追記する -
README.mdとdocs/remaining-migration-items.mdの進捗前提を定期的に同期する - Java 版移植の現在地を、core 完了率と CLI/report 完了率で分けて示す
-
vendor/mikuprojectに Node.js upstream を subtree で保持する -
workplace/は Git 管理外のローカル作業スペースとして扱う - Java package の基底名を
jp.igapyon.mikuprojectにする - Java のターゲットを
1.8にする - Maven ベースで開始する
- Node.js upstream の構成を尊重し、Java 側の責務分割も対応関係を追いやすくする
- Java 版の初期移植の目的を明文化する
-
MS Project XMLとProjectModelの位置づけを Java 版でも定義する - Java 版
ProjectModelの責務と範囲を決める - 初期移植で扱う要素範囲を決める
- CLI を初期移植に含めるか決める
-
ProjectModelをMapベースで持つか、POJO で持つか方針を決める - ソースヘッダーにライセンス表記を追加する