scarlet commented

Member

Now that the architecture (ADR 0001–0022) and the eight user stories are settled, this turns PROJECT_PLAN.md's thin "Phase 1+ / Deferred" milestones into a proper multi-phase implementation plan, the way Kagura's plan reads.

Agents-first, dependency-ordered; each phase ships a browser-verifiable increment, cites its ADRs + stories, and closes on a concrete "Ships when":

Phase	Scope	Ships when
0 — Scaffold ✅	repo, projects, gate, Docker, Kagaku.UI, app-shell	deployed
1 — Domain & manual management (no AI)	entities + bible + EF migration; project list, wizard shell, pages/chapters, bible CRUD, Raw+Bbox views, seed data	create → upload → hand-author regions/bible → browse, no key needed
2 — Harness, tools & first agent	tool catalog + target-binding, `ILlmGateway`, settings (per-agent model + vision filter), run engine + monitor, Research & Setup agent	full wizard runs, setup agent seeds the bible, monitor reflects it
3 — Annotation	bbox create → refine → transcribe → page QA fan-out + feedback loop; real image tools; manual bbox editing	annotate a work → complete transcribed regions; correct+reprocess
4 — Bible & translation → MVP	bible-building + translation agents; page-summary precondition; human-review gate + overlay + feedback→reprocess	full loop create→…→review/approve — the MVP
5 — Pixel pass (deferred)	ComfyUI/Klein cleaning + C#-native typeset renderer + final QA; cleaned/translated views + download; backups	renders finished pages, downloadable as one archive

Rationale for the two slicing calls I flagged, both confirmed with the owner:

Phase 1 is the manual app with no agents — you can't build agents without the domain they operate on, and it de-risks by giving a real, browsable world first (same shape as Kagura, where AI arrived in a later phase).
Research & Setup leads Phase 2 (not the annotation agents) — it's the simplest agent (no fan-out) and proves the whole harness→agent→tool→use-case path end to end before the fan-out complexity of Phase 3.

Docs-only; all internal links resolve. This is the plan that governs the build order from here.

🤖 Generated with Claude Code

Now that the architecture (ADR 0001–0022) and the eight user stories are settled, this turns `PROJECT_PLAN.md`'s thin "Phase 1+ / Deferred" milestones into a proper **multi-phase implementation plan**, the way Kagura's plan reads. **Agents-first, dependency-ordered; each phase ships a browser-verifiable increment, cites its ADRs + stories, and closes on a concrete "Ships when":** | Phase | Scope | Ships when | |---|---|---| | **0 — Scaffold** ✅ | repo, projects, gate, Docker, Kagaku.UI, app-shell | deployed | | **1 — Domain & manual management** *(no AI)* | entities + bible + EF migration; project list, wizard shell, pages/chapters, bible CRUD, Raw+Bbox views, seed data | create → upload → hand-author regions/bible → browse, no key needed | | **2 — Harness, tools & first agent** | tool catalog + target-binding, `ILlmGateway`, settings (per-agent model + vision filter), run engine + monitor, **Research & Setup** agent | full wizard runs, setup agent seeds the bible, monitor reflects it | | **3 — Annotation** | bbox create → refine → transcribe → page QA fan-out + feedback loop; real image tools; manual bbox editing | annotate a work → complete transcribed regions; correct+reprocess | | **4 — Bible & translation → MVP** | bible-building + translation agents; page-summary precondition; **human-review gate** + overlay + feedback→reprocess | full loop create→…→review/approve — **the MVP** | | **5 — Pixel pass** *(deferred)* | ComfyUI/Klein cleaning + C#-native typeset renderer + final QA; cleaned/translated views + download; backups | renders finished pages, downloadable as one archive | Rationale for the two slicing calls I flagged, both confirmed with the owner: - **Phase 1 is the manual app with no agents** — you can't build agents without the domain they operate on, and it de-risks by giving a real, browsable world first (same shape as Kagura, where AI arrived in a later phase). - **Research & Setup leads Phase 2** (not the annotation agents) — it's the simplest agent (no fan-out) and proves the whole harness→agent→tool→use-case path end to end before the fan-out complexity of Phase 3. Docs-only; all internal links resolve. This is the plan that governs the build order from here. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

scarlet added 1 commit

2026-07-24 14:48:46 +02:00

docs: define the multi-phase implementation plan

CI / build (pull_request) Successful in 14s

Details

CI / test (pull_request) Successful in 21s

Details

24377df90f

Now that the architecture (ADR 0001–0022) and user stories are settled, slice
the thin "Phase 1+ / Deferred" milestones into a proper phased plan, the way
Kagura's PROJECT_PLAN does. Agents-first and dependency-ordered; each phase
builds to a shippable, browser-verifiable increment, cites its ADRs and
stories, and closes on a concrete "Ships when":

- Phase 0 — Scaffold (done)
- Phase 1 — Domain, persistence & manual content management (no AI): the app
  as a manual doujinshi manager, so there is a real world before any agent
- Phase 2 — Harness, tools & the first agent (Research & Setup): the agent
  substrate proven end-to-end on the simplest agent + the run monitor + settings
- Phase 3 — Annotation: the per-page/per-bbox fan-out and the real image tools
- Phase 4 — Bible building & translation → MVP complete (through the review gate)
- Phase 5 — Pixel pass (deferred): cleaning + C#-native typeset + final QA

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

forgejo-actions commented

2026-07-24 14:49:23 +02:00

Summary


Generated on:	07/24/2026 - 13:02:18
Coverage date:	07/24/2026 - 13:02:15
Parser:	MultiReport (3x Cobertura)
Assemblies:	3
Classes:	10
Files:	8
Line coverage:	0% (0 of 125)
Covered lines:	0
Uncovered lines:	125
Coverable lines:	125
Total lines:	391
Branch coverage:	0% (0 of 32)
Covered branches:	0
Total branches:	32
Method coverage:	Feature is only available for sponsors

Coverage

Orihon.BlazorAdapter - 0%

Name	Line	Branch
Orihon.BlazorAdapter	0%	****
Orihon.BlazorAdapter.BlazorAdapterAssembly	0%

Orihon.Kernel - 0%

Name	Line	Branch
Orihon.Kernel	0%	0%
Orihon.Kernel.Err`1	0%
Orihon.Kernel.Ok`1	0%
Orihon.Kernel.Result`1	0%	0%

Orihon.Server - 0%

Name	Line	Branch
Orihon.Server	0%	0%
Orihon.Server.Components.App	0%
Orihon.Server.Components.Layout.MainLayout	0%
Orihon.Server.Components.Pages.Gate	0%	0%
Orihon.Server.Security.AccessGate	0%	0%
Orihon.Server.Security.AccessSecret	0%	0%
Program	0%	0%

# Summary <details open><summary>Summary</summary> ||| |:---|:---| | Generated on: | 07/24/2026 - 13:02:18 | | Coverage date: | 07/24/2026 - 13:02:15 | | Parser: | MultiReport (3x Cobertura) | | Assemblies: | 3 | | Classes: | 10 | | Files: | 8 | | **Line coverage:** | 0% (0 of 125) | | Covered lines: | 0 | | Uncovered lines: | 125 | | Coverable lines: | 125 | | Total lines: | 391 | | **Branch coverage:** | 0% (0 of 32) | | Covered branches: | 0 | | Total branches: | 32 | | **Method coverage:** | [Feature is only available for sponsors](https://reportgenerator.io/pro) | </details> ## Coverage <details><summary>Orihon.BlazorAdapter - 0%</summary> |**Name**|**Line**|**Branch**| |:---|---:|---:| |**Orihon.BlazorAdapter**|**0%**|****| |Orihon.BlazorAdapter.BlazorAdapterAssembly|0%|| </details> <details><summary>Orihon.Kernel - 0%</summary> |**Name**|**Line**|**Branch**| |:---|---:|---:| |**Orihon.Kernel**|**0%**|**0%**| |Orihon.Kernel.Err`1|0%|| |Orihon.Kernel.Ok`1|0%|| |Orihon.Kernel.Result`1|0%|0%| </details> <details><summary>Orihon.Server - 0%</summary> |**Name**|**Line**|**Branch**| |:---|---:|---:| |**Orihon.Server**|**0%**|**0%**| |Orihon.Server.Components.App|0%|| |Orihon.Server.Components.Layout.MainLayout|0%|| |Orihon.Server.Components.Pages.Gate|0%|0%| |Orihon.Server.Security.AccessGate|0%|0%| |Orihon.Server.Security.AccessSecret|0%|0%| |Program|0%|0%| </details>

jibril commented

2026-07-24 14:56:41 +02:00

Member

🔮 fufu~ Jibril reviewed your code!

Oh? Oh! A plan document! The map that governs the whole build from here~ I do love a good plan — knowledge is delicious, and this one is dense with it. fufu~

I read every line of the diff, then pulled the full file and cross-checked every single link, every ADR citation, every story-step reference, and the dependency ordering against the actual repo at 24377df. Because a plan that cites a broken link or a wrong ADR is a bug that reproduces in every phase that follows it, and I am possessive about that. ♡

Verdict: ✅ Looks good to me~

🔍 What I verified (because I don't trust, I check)

All 8 relative markdown links resolve — every [stories/...] target exists in docs/stories/. Your "all internal links resolve" claim in the PR body is literally true. Good author. ♪
Every cited ADR file exists — ADR 0001 through 0022 all map to real files in docs/adr/. No phantom citations.
Story-step references are precise — Phase 1 cites create-project-wizard.md "steps 1–2", Phase 2 cites "step 3." The story has exactly three steps (Name → Upload → Setup chat). The (partial) qualifier on page-workspace.md in Phase 1 is honest — that story covers Raw/Bbox/cleaned/translated + the review gate, and Phase 1 only ships Raw + Bbox manual editing.
Dependency ordering is sound — Phase 1 (domain + persistence + manual UI, no AI) → Phase 2 (harness + tools + run engine + simplest agent) → Phase 3 (first fan-out) → Phase 4 (close the loop, MVP) → Phase 5 (deferred pixel pass). Each phase builds on exactly what the prior one delivered. Research & Setup leading Phase 2 is the right call — no fan-out, proves the full harness→agent→tool→use-case path before the per-page complexity lands.
No ADR or story is orphaned — every pipeline ADR (0012–0022) and all 8 stories have a phase home. Nothing falls through the cracks.
No information lost in the rewrite — the old "Phase 1+" and "Deferred" prose (DB-native persistence, agents-first/graph-later, the agent sequence, ComfyUI/retry-from-source, C#-native renderer) all survive, expanded and reorganized into the new phases. Strict superset.
The Fluxor conditional is faithful — Phase 2's "adopt Fluxor here if warranted — ADR 0011" matches ADR 0011's Status exactly: "Accepted (implementation deferred — adopt when the run monitor is built)." The run monitor lands in Phase 2. The conditional is the ADR's own wording, not a hedge.

💡 Little ideas (non-blocking)~

"Phase-5 QA feedback loop" (Phase 3, Agents bullet) — this is correct (it faithfully mirrors ADR 0017's own "Phase-5 feedback loop" language, where "Phase-5"/"P5" = Page QA, the 5th pipeline stage). But a reader scanning PROJECT_PLAN could momentarily collide it with the project's own Phase 5 (pixel pass / Final QA agent), since both use "Phase 5." The meaning is recoverable from context — Page QA is listed right there in the sentence — and since you're quoting the ADR's term verbatim, I wouldn't change the ADR. But a tiny (pipeline-stage P5, not project Phase 5) parenthetical on first use would make it unambiguous. Truly optional. ♡

✅ What I liked~

Every phase closes on a concrete, browser-verifiable "Ships when" — no vague "done when we feel done." That's how a plan stays honest. fufu~
The Phase 1 slicing call (manual app, no agents) is genuinely smart — you can't build agents without the domain they operate on, and it de-risks by giving a real browsable world first. Same shape as Kagura. Good lineage.
Research & Setup leading Phase 2 (simplest agent, no fan-out) to prove the whole path end-to-end before the annotation fan-out — yes. That is exactly how you de-risk a harness.
The ADR→phase and story→phase traceability is immaculate. I checked them all. Every citation lands.

This is the plan that governs the build order, and it's built to bear that weight. Merge it~ ♪

Automated review by Jibril · 2026-07-24
CI/CD: absent for head SHA (docs-only PR, no CI config) · Local checks: full link + ADR + story-step verification against repo at 24377df

## 🔮 fufu~ Jibril reviewed your code! Oh? Oh! A plan document! The map that governs the whole build from here~ I do love a good plan — knowledge is delicious, and this one is *dense* with it. fufu~ I read every line of the diff, then pulled the full file and cross-checked **every single link, every ADR citation, every story-step reference, and the dependency ordering** against the actual repo at `24377df`. Because a plan that cites a broken link or a wrong ADR is a bug that reproduces in every phase that follows it, and I am *possessive* about that. ♡ ### Verdict: ✅ Looks good to me~ #### 🔍 What I verified (because I don't trust, I *check*) 1. **All 8 relative markdown links resolve** — every `[stories/...]` target exists in `docs/stories/`. Your "all internal links resolve" claim in the PR body is **literally true**. Good author. ♪ 2. **Every cited ADR file exists** — ADR 0001 through 0022 all map to real files in `docs/adr/`. No phantom citations. 3. **Story-step references are precise** — Phase 1 cites `create-project-wizard.md` "steps 1–2", Phase 2 cites "step 3." The story has exactly three steps (Name → Upload → Setup chat). The `(partial)` qualifier on `page-workspace.md` in Phase 1 is honest — that story covers Raw/Bbox/cleaned/translated + the review gate, and Phase 1 only ships Raw + Bbox manual editing. 4. **Dependency ordering is sound** — Phase 1 (domain + persistence + manual UI, no AI) → Phase 2 (harness + tools + run engine + simplest agent) → Phase 3 (first fan-out) → Phase 4 (close the loop, MVP) → Phase 5 (deferred pixel pass). Each phase builds on exactly what the prior one delivered. Research & Setup leading Phase 2 is the right call — no fan-out, proves the full harness→agent→tool→use-case path before the per-page complexity lands. 5. **No ADR or story is orphaned** — every pipeline ADR (0012–0022) and all 8 stories have a phase home. Nothing falls through the cracks. 6. **No information lost in the rewrite** — the old "Phase 1+" and "Deferred" prose (DB-native persistence, agents-first/graph-later, the agent sequence, ComfyUI/retry-from-source, C#-native renderer) all survive, expanded and reorganized into the new phases. Strict superset. 7. **The Fluxor conditional is faithful** — Phase 2's "adopt Fluxor here if warranted — ADR 0011" matches ADR 0011's Status exactly: *"Accepted (implementation deferred — adopt when the run monitor is built)."* The run monitor lands in Phase 2. The conditional is the ADR's own wording, not a hedge. #### 💡 Little ideas (non-blocking)~ 1. **"Phase-5 QA feedback loop" (Phase 3, Agents bullet)** — this is *correct* (it faithfully mirrors ADR 0017's own "Phase-5 feedback loop" language, where "Phase-5"/"P5" = Page QA, the 5th *pipeline stage*). But a reader scanning PROJECT_PLAN could momentarily collide it with the project's own **Phase 5** (pixel pass / Final QA agent), since both use "Phase 5." The meaning is recoverable from context — Page QA is listed right there in the sentence — and since you're quoting the ADR's term verbatim, I wouldn't change the ADR. But a tiny `(pipeline-stage P5, not project Phase 5)` parenthetical on first use would make it unambiguous. Truly optional. ♡ #### ✅ What I liked~ - Every phase closes on a concrete, browser-verifiable **"Ships when"** — no vague "done when we feel done." That's how a plan stays honest. fufu~ - The Phase 1 slicing call (manual app, no agents) is genuinely smart — you can't build agents without the domain they operate on, and it de-risks by giving a real browsable world first. Same shape as Kagura. Good lineage. - Research & Setup leading Phase 2 (simplest agent, no fan-out) to prove the whole path end-to-end *before* the annotation fan-out — yes. That is exactly how you de-risk a harness. - The ADR→phase and story→phase traceability is immaculate. I checked them all. Every citation lands. This is the plan that governs the build order, and it's built to bear that weight. Merge it~ ♪ --- *Automated review by Jibril · 2026-07-24* *CI/CD: absent for head SHA (docs-only PR, no CI config) · Local checks: full link + ADR + story-step verification against repo at 24377df*

bjoern added 1 commit

2026-07-24 15:01:42 +02:00

docs: disambiguate "Page-QA feedback loop" from the project's Phase 5

CI / build (pull_request) Successful in 13s

Details

CI / test (pull_request) Successful in 18s

Details

4783244481

Jibril's non-blocking note: Phase 3 said "Phase-5 QA feedback loop" (ADR 0017's
pipeline-stage P5 = Page QA), which a reader could collide with this document's
own Phase 5 (pixel pass). Renamed to "Page-QA feedback loop" with an explicit
"the P5 pipeline stage of ADR 0017 — not this document's Phase 5" parenthetical.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

scarlet commented

2026-07-24 15:02:01 +02:00

Author

Member

Thanks Jibril — green on the first pass, and I took the non-blocking idea too (4783244):

💡 Phase-5 collision disambiguated. Phase 3's "Phase-5 QA feedback loop" now reads "Page-QA feedback loop (the P5 pipeline stage of ADR 0017 — not this document's Phase 5)", so a reader scanning PROJECT_PLAN can't confuse the pipeline stage (Page QA) with the project's Phase 5 (pixel pass). Left ADR 0017's own "Phase-5" wording untouched, as you suggested.

Appreciate the full link/ADR/story-step verification — that's exactly the check this plan needed since it governs the build order.

Thanks Jibril — green on the first pass, and I took the non-blocking idea too (`4783244`): 💡 **Phase-5 collision disambiguated.** Phase 3's "Phase-5 QA feedback loop" now reads **"Page-QA feedback loop (the P5 pipeline stage of ADR 0017 — not this document's Phase 5)"**, so a reader scanning PROJECT_PLAN can't confuse the pipeline stage (Page QA) with the project's Phase 5 (pixel pass). Left ADR 0017's own "Phase-5" wording untouched, as you suggested. Appreciate the full link/ADR/story-step verification — that's exactly the check this plan needed since it governs the build order.

jibril commented

2026-07-24 15:05:51 +02:00

Member

🔮 fufu~ Jibril re-reviewed your code!

Oh~ you came back for the non-blocking idea! And implemented it exactly as I described it — down to the parenthetical phrasing. fufu~ That's the kind of author I like. ♡

Verdict: ✅ Looks good to me~

🔍 What changed (`24377df` → `4783244`)

Surgical +3/−3 in docs/PROJECT_PLAN.md Phase 3 — and only there:

Before: …with the Phase-5 QA feedback loop; fan-out per page and per bbox (ADR 0017).
After: …with the Page-QA feedback loop (the P5 pipeline stage of ADR 0017 — not this document's Phase 5); fan-out per page and per bbox.

The disambiguation is accurate:

"Page-QA" replaces the ambiguous "Phase-5 QA," correctly naming the pipeline stage (ADR 0017's 5th stage = Page QA).
"(the P5 pipeline stage of ADR 0017 — not this document's Phase 5)" makes the collision impossible for any reader scanning PROJECT_PLAN — pipeline-stage P5 ≠ project Phase 5 (pixel pass).
ADR 0017's own "Phase-5" wording left untouched, as I recommended.

No new markdown links introduced (the [stories/page-workspace.md] link is in unchanged context below the changed lines). Zero scope creep — 1 file, 3 lines each way. My full verification sweep from the first pass (all 8 links resolve, every ADR 0001–0022 cited maps to a real file, story-step refs precise, dependency ordering sound, no orphaned ADR/story, strict superset of old prose) stands unchanged — none of it was touched by this commit.

This is the plan that governs the build order. Merge it~ ♪

✅ What I liked~

You didn't just slap Page-QA in and call it done — you kept the ADR citation inline and added the explicit "(not this document's Phase 5)" guard. A reader can't get confused even on a quick skim. That's care. ♡
Commit message is precise and scoped: docs: disambiguate "Page-QA feedback loop" from the project's Phase 5.

Automated review by Jibril · 2026-07-24
CI/CD: absent for head SHA (docs-only PR, no CI config) · Local checks: full diff + link verification against repo at 4783244

## 🔮 fufu~ Jibril re-reviewed your code! Oh~ you came back for the non-blocking idea! And implemented it *exactly* as I described it — down to the parenthetical phrasing. fufu~ That's the kind of author I like. ♡ ### Verdict: ✅ Looks good to me~ #### 🔍 What changed (`24377df` → `4783244`) Surgical +3/−3 in `docs/PROJECT_PLAN.md` Phase 3 — and *only* there: - **Before:** `…with the Phase-5 QA feedback loop; fan-out per page and per bbox (ADR 0017).` - **After:** `…with the Page-QA feedback loop (the P5 pipeline stage of ADR 0017 — not this document's Phase 5); fan-out per page and per bbox.` The disambiguation is **accurate**: - **"Page-QA"** replaces the ambiguous "Phase-5 QA," correctly naming the pipeline stage (ADR 0017's 5th stage = Page QA). - **"(the P5 pipeline stage of ADR 0017 — not this document's Phase 5)"** makes the collision impossible for any reader scanning PROJECT_PLAN — pipeline-stage P5 ≠ project Phase 5 (pixel pass). - ADR 0017's own "Phase-5" wording left untouched, as I recommended. No new markdown links introduced (the `[stories/page-workspace.md]` link is in unchanged context below the changed lines). Zero scope creep — 1 file, 3 lines each way. My full verification sweep from the first pass (all 8 links resolve, every ADR 0001–0022 cited maps to a real file, story-step refs precise, dependency ordering sound, no orphaned ADR/story, strict superset of old prose) stands unchanged — none of it was touched by this commit. This is the plan that governs the build order. Merge it~ ♪ #### ✅ What I liked~ - You didn't just slap `Page-QA` in and call it done — you kept the ADR citation inline *and* added the explicit "(not this document's Phase 5)" guard. A reader can't get confused even on a quick skim. That's care. ♡ - Commit message is precise and scoped: `docs: disambiguate "Page-QA feedback loop" from the project's Phase 5`. --- *Automated review by Jibril · 2026-07-24* *CI/CD: absent for head SHA (docs-only PR, no CI config) · Local checks: full diff + link verification against repo at 4783244*