[plan] Phase 計画と timeline

[sotashimozono]

Question

何 Phase に分けて、どの順で何週間で進めるか。

Default plan

Phase	スコープ	工数
0	repo init, Cargo workspace, CI (clippy + fmt + test), --help	1 日
1	core resolver + Crossref/Unpaywall/arXiv source + fetch / batch	1 週
2	TOML store (BiblioFetch.jl 互換) + info / search / bib / csl	1 週
3	serve MCP server (stdio) + 5 つの基本 tool	1 週
4	S2 / OpenAlex / DOAJ + citation graph	4 日
5	TDM 3 source (APS / Elsevier / Springer)	4 日
6	MCP marketplace 登録 + landing page + --json polish	3 日
7	(optional) vault, analytics, run job.toml	1 週

MVP (Phase 0-3) で 3 週間 で「DOI 投げたら PDF と JSON で返す MCP server」完成。

Open questions

• Phase 順序入れ替えるべき？(例: Phase 6 marketing を Phase 3 直後)
• 並列 agent dispatch で工数圧縮するか solo dev で順次か
• 着手タイミング: 今すぐ / 連載 BiblioFetch 記事 publish 完了後 (5/9) / 来週

Decision

???

[sotashimozono]

Filed as external review by Claude (Anthropic, AI agent operating under souta's GitHub auth). This is the integrated Phase plan recompute after reviewing all 15 sibling Discussions.

立場

本文 default plan (Phase 0-7、 MVP は Phase 0-3 で 3 週間) の 大枠は維持。 但し各 Phase の中身を、 sibling Discussion に対する reviewer Decision proposal で増えた deliverable で再見積もり。 結果として MVP が 3 週間 → 5 週間 に拡大します。

1. Phase 別の deliverable 確定 list

各 Phase の deliverable を、 関連 Discussion ごとに紐付けて lock。

Phase 0 — Repo bootstrap + foundational specs (5-7 日、 既存 1 日 → 拡大)

Code:

• Cargo workspace skeleton: doiget-core / doiget-cli (Phase 3 で doiget-mcp 追加)
• --help 動く CLI (no subcommands)
• cargo build --features oa-only 成功 (default)

Docs (NORMATIVE):

• README.md ([legal] Legal posture, tool neutrality framing, and required safeguards #16 §posture / [infra] ドキュメント整備の戦略 (README / docs/ / mdbook / rustdoc) #11 §persona-table)
• LICENSE (MIT + 追加コメント)
• CONTACT.md ([legal] Legal posture, tool neutrality framing, and required safeguards #16 §7 SLA / escalation / DMCA)
• docs/LEGAL.md ([legal] Legal posture, tool neutrality framing, and required safeguards #16 全文 + jurisdictional caveat)
• docs/SCOPE.md ([scope] PDF の内容操作 (extract / OCR / 要約) は in-scope か out-of-scope か #9 / [design] MCP transport — stdio only or HTTP also #4 §Permanent non-goals)
• docs/SECURITY.md ([security] threat model + security 対策 #12 全 threat surface + supply-chain)
• docs/STORE.md ([design] BiblioFetch.jl との共存モデル #1 / [design] BiblioFetch.jl と TOML store の互換性レベル #2 §Contract 1-4)
• docs/SAFEKEY.md ([design] BiblioFetch.jl との共存モデル #1 §Contract 4 + 100 test vectors)
• docs/CONFIG.md ([infra] 共通基盤 (logging / errors / config / test fixtures) #13 §config / env var precedence)
• docs/PUBLIC_API.md ([ux] User personas + 出力 mode 設計 (agent / researcher / CI / library) #14 §3 — 但し interface 宣言のみ、 実装は Phase 1)
• docs/CACHE.md ([design] MCP server が公開する tool の名前と signature #8 §4 / [design] Citation graph 機能を Phase 1 必須にするか後ろ倒しか #6 §5)
• docs/ERRORS.md ([ux] User personas + 出力 mode 設計 (agent / researcher / CI / library) #14 §7 persona × error code matrix)
• CHANGELOG.md (Keep a Changelog format、 [infra] ドキュメント整備の戦略 (README / docs/ / mdbook / rustdoc) #11 §8)

Docs (INFORMATIVE):

• CONTRIBUTING.md (PR 規約、 doc style)
• docs/ARCHITECTURE.md (mermaid diagram)
• docs/PHASES.md (本 Discussion 内容のスナップショット)
• docs/MIGRATION.md ([design] BiblioFetch.jl との共存モデル #1 §Migration story、 placeholder)
• docs/DECISIONS/INDEX.md + 0001-0010 ADRs

CI:

• .github/workflows/ci.yml (lint / clippy / test / 9-job matrix [infra] .github/workflows/ の CI / CD pipeline 設計 #10 §3)
• .github/workflows/audit.yml (cargo audit + cargo deny)
• .github/workflows/posture-lint.yml ([legal] Legal posture, tool neutrality framing, and required safeguards #16 §6 / [infra] .github/workflows/ の CI / CD pipeline 設計 #10 §1)
• .github/workflows/codeql.yml ([infra] .github/workflows/ の CI / CD pipeline 設計 #10 §11 — Phase 0 から)
• .github/workflows/safekey-vectors.yml ([infra] .github/workflows/ の CI / CD pipeline 設計 #10 §1)
• .github/workflows/cross-tool-compat.yml ([design] BiblioFetch.jl との共存モデル #1 / [infra] .github/workflows/ の CI / CD pipeline 設計 #10 §1 — placeholder で Julia install のみ、 actual round-trip は Phase 2 で)
• .github/workflows/dependabot.yml ([infra] .github/workflows/ の CI / CD pipeline 設計 #10 §10、 auto-merge 無効)
• Branch protection + 2FA + signed commit 要件 ([security] threat model + security 対策 #12 §threat 1)

Configuration files:

• Cargo.toml workspace + [features] (oa-only / metadata / tdm-* placeholder [design] APS / Elsevier / Springer TDM の実装優先度 #5)
• Cargo.lock commit
• rust-toolchain.toml (MSRV pin [infra] .github/workflows/ の CI / CD pipeline 設計 #10 §4)
• deny.toml ([infra] 共通基盤 (logging / errors / config / test fixtures) #13 §4 deny list)
• .cargo/config.toml (build flags)
• clippy.toml (print_stdout deny in mcp crate [ux] User personas + 出力 mode 設計 (agent / researcher / CI / library) #14 §2)

Test fixtures:

• tests/fixtures/safekey/vectors.json (100 entries)
• tests/fixtures/golden/ (placeholder)

工数: 5-7 日 (本文 1 日 → 拡大)。 理由: 多数の normative spec を全部 Phase 0 で書くため。 但し具象 code は 1 日分のみ。 残りは doc 仕事 + CI 設定。

Phase 1 — Core resolver + Tier 1 sources + fetch CLI (1.5 週、 本文 1 週 → 拡大)

Code:

• Source trait + Crossref / Unpaywall / arXiv impl
• Resolver (DOI / arXiv id 判別 + Source 順序)
• CapabilityProfile 実装 ([legal] Legal posture, tool neutrality framing, and required safeguards #16 §7) — Phase 1 から hard-gate 機能あり
• Store trait + filesystem impl (atomic write + flock — [design] BiblioFetch.jl との共存モデル #1 §Contract 2-3)
• safekey algorithm — docs/SAFEKEY.md の test vectors を全 pass
• Provenance log — JSON Lines + SHA256 hash chain ([security] threat model + security 対策 #12 §threat 4)
• doiget fetch <ref> / doiget batch <refs.txt> CLI
• 入力 validation (DOI / arXiv id 厳密 regex、 [security] threat model + security 対策 #12 §threat 2)
• Rate limit hard-cap (MAX_CONCURRENT_FETCHES = 5、 [legal] Legal posture, tool neutrality framing, and required safeguards #16 §8)

Tests:

• Unit + integration + golden + property ([infra] 共通基盤 (logging / errors / config / test fixtures) #13 §8)
• tests/cli_fetch.rs を assert_cmd で

工数: 1.5 週 (本文 1 週 → 拡大)。 理由: CapabilityProfile / hash chain log / atomic write + flock を Phase 1 で揃えるため。

Phase 2 — Store + info / search / bib / csl (1 週、 本文通り)

Code:

• doiget info <ref> / doiget list-recent / doiget search <query>
• doiget bib <filter?> / doiget csl <filter?>
• TOML normalization ([design] BiblioFetch.jl と TOML store の互換性レベル #2 §規律 5)
• BiblioFetch.jl ↔ doiget round-trip integration test ([design] BiblioFetch.jl との共存モデル #1 / [infra] .github/workflows/ の CI / CD pipeline 設計 #10 §1) を 完成版 で

工数: 1 週 (本文通り)。

Phase 3 — MCP server + 9 tools + 厳格 stdio (1.5 週、 本文 1 週 → 拡大)

Code:

• doiget serve MCP server (stdio only、 [design] MCP transport — stdio only or HTTP also #4)
• 9 tools ([design] MCP server が公開する tool の名前と signature #8 §6 — 6 from 本文 + 3 追加: paper_pdf_path / capability_profile / health)
• JSON Schema in inputSchema ([design] MCP server が公開する tool の名前と signature #8 §5)
• tracing-subscriber redirect to stderr 強制 ([ux] User personas + 出力 mode 設計 (agent / researcher / CI / library) #14 §2)
• Panic hook stderr 強制
• Backpressure / queue depth 100 上限 ([design] MCP transport — stdio only or HTTP also #4 §Backpressure)
• mcp-smoke.yml CI ([infra] .github/workflows/ の CI / CD pipeline 設計 #10 §12)

Docs:

• docs/MCP_TOOLS.md を完成版に (NORMATIVE — [infra] ドキュメント整備の戦略 (README / docs/ / mdbook / rustdoc) #11 §1)
• docs/INTEGRATION/claude-desktop.md / cursor.md / codex.md / claude-code.md

工数: 1.5 週 (本文 1 週 → 拡大)。 理由: stdout noise 0 byte の hard enforcement と MCP 入力 validation で +3 日。

Phase 4 — Tier 2 sources + citation graph (1.5 週、 本文 4 日 → 拡大)

Code (#3 §規律 / #6 §6):

• OpenAlex / Semantic Scholar / DOAJ source 追加
• expand_citation_graph 実装 (BFS + visited set + hard-cap、 [design] Citation graph 機能を Phase 1 必須にするか後ろ倒しか #6 §1-4)
• ~/.cache/doiget/citations/ cache layer ([design] Citation graph 機能を Phase 1 必須にするか後ろ倒しか #6 §5)
• mermaid / DOT format generator
• doiget_expand_citation_graph MCP tool

工数: 1.5 週 (本文 4 日 → 拡大)。 #6 review §6 の breakdown 通り。

Phase 5 — TDM (5a / 5b / 5c に分割、 各 1 週)

前提条件: Phase 0-4 の production usage data (provenance log の access pattern + GitHub Discussion での actual demand) を見て、 author が 明示的に着手判断。 「自動的に着手」しない (#5)。

Phase 5a — Springer Nature OA (1 週):

• tdm-springer-oa feature flag 追加
• compile-time gating ([legal] Legal posture, tool neutrality framing, and required safeguards #16 §6)
• Source 実装 + capability profile 統合
• Cooldown 期間 1-2 週 (publisher 側からのフィードバックを観察)

Phase 5b — APS Harvest TDM (1 週):

• 同上、 tdm-aps
• Cooldown 期間 1-2 週

Phase 5c — Elsevier ScienceDirect TDM (1 週):

• 同上、 tdm-elsevier
• author の 再 Decision 必須 (Phase 5b までで polite email / cease-and-desist が来ていないことが前提)

合計 3-5 週 (cooldown 含む)。 Phase 5 全体は author 判断次第で skip 可 (#5 §"延期 or 無期限保留")。

Phase 6 — Release + marketplace + polish (1 週、 本文 3 日 → 拡大)

Release:

• crates.io trusted publishing (OIDC、 [infra] .github/workflows/ の CI / CD pipeline 設計 #10 §2)
• sigstore keyless signing ([infra] .github/workflows/ の CI / CD pipeline 設計 #10 §2)
• environment-protected workflow ([infra] .github/workflows/ の CI / CD pipeline 設計 #10 §2)
• SBOM 生成 ([infra] .github/workflows/ の CI / CD pipeline 設計 #10 §9)
• musl static (Linux) / universal (macOS) / msvc (Windows)

Marketplace:

• Anthropic MCP marketplace 登録
• Cursor / Codex の install snippet ([infra] ドキュメント整備の戦略 (README / docs/ / mdbook / rustdoc) #11 §INTEGRATION/)
• Landing page (HN submit 用)、 但し marketing 用語 self-policing ([legal] Legal posture, tool neutrality framing, and required safeguards #16 §6)

Docs polish:

• README brushup
• 日本語版 docs/ja/ (Phase 6 で開始、 全 Phase 完了は Phase 7+)

工数: 1 週 (本文 3 日 → 拡大)。

Phase 7 — Optional (1 週 / 機能ごと、 本文通り)

• vault (Obsidian sync、 [integration] Obsidian backend として使いやすい設計 #15) — 別 crate doiget-obsidian、 default OFF
• analytics / run job.toml 等

2. Total timeline (recompute)

Phase	工数	累計
Phase 0	5-7 日	1 週
Phase 1	1.5 週	2.5 週
Phase 2	1 週	3.5 週
Phase 3	1.5 週	5 週
MVP shipping point		5 週 (本文 3 週 → 拡大)
Phase 4	1.5 週	6.5 週
Phase 5 (optional)	3-5 週	9.5-11.5 週
Phase 6	1 週	10.5-12.5 週
Phase 7 (optional)	per feature	n/a

MVP (Phase 0-3) で 5 週間 (本文 3 週間 → 5 週間)。 deliverable を技術的に守りきれる range に再見積もり。

3. 着手 timing と並列性

本文 open question への reviewer 回答:

• 並列 agent dispatch 推奨: docs (Phase 0) と code (Phase 1) は別 agent で並行進行可能。 souta + AI agents で 工数を 2-3 倍速に圧縮できる
• 着手 timing: 連載 BiblioFetch 記事 publish 完了 (5/9) 後 が推奨。 doiget release 時に「BiblioFetch.jl の agent 版」として cross-promote できる

4. Phase 順序の入れ替え提案

本文 open question への reviewer 回答:

• Phase 6 (release / marketplace) を Phase 3 直後に部分前倒し
  • Phase 3 完了 = MVP 完成。 marketplace 登録 / landing page draft を ここで打って、 Phase 4 の citation graph は MVP user feedback を見ながら 着手するほうが yagni 防止
• 但し full release は Phase 6 で一括 (release.yml / sigstore / SBOM 等は Phase 3 で前倒ししない)
• Order: Phase 0 → 1 → 2 → 3 → 3.5 (early marketplace draft) → 4 → 5 (optional) → 6 (full release) → 7 (optional)

5. Pre-flight checklist (Phase 0 着手前に確定すべきこと)

reviewer 観点で、 Phase 0 を始める前に このプラン以外 に lock しておくべきこと:

• BiblioFetch.jl 側の safekey algorithm が現状で stable か (BiblioFetch.jl の H2 issue が解決済みか) — 確認後 100 test vectors を共有 spec 化
• BiblioFetch.jl 現行 schema_version (= 1.0?) を確認
• crates.io trusted publishing の設定権限 (souta の crates.io account 状態)
• GitHub Environment 機能の repo 設定権限
• sigstore / cosign の GitHub Actions 権限

Reviewer Decision proposal

• Phase 別 deliverable list を本 review §1 で確定 (各 Phase で何を出すかの normative checklist)
• MVP 工数を 3 週間 → 5 週間に再見積もり
• Phase 5 は author 判断次第で skip 可、 着手は production data 駆動
• Phase 順序: 3 → 3.5 (early marketplace) → 4 → 5 (optional) → 6 (full release)
• Phase 0 は 並列 agent dispatch を活用 して docs / code 同時進行
• Pre-flight checklist を満たしてから Phase 0 着手

最終 Decision 権は author に留保。

---

Reviewer: Claude (Anthropic). Filed 2026-05-05.