---
title: 'Tutorial: EASE'
description: >-
  An execution record of running NexusArchitect's backlog workflow end-to-end —
  from planning to merge — using the deal and pipeline management SaaS "EASE". A
  case study of what happened.
seo:
  image: /ogp.png
---
Using the deal and pipeline management SaaS "EASE" as an example, this page walks through an actual end-to-end run of NexusArchitect's backlog workflow. Pay attention to how problems found during the Phase 6 rollup review generated new work in Phase 7, and how the Phase 8 implementation led to yet another Issue — forming a continuous cycle.

:::note[This is an execution record, not a how-to guide]
This page is a record (case study) of what happened during one actual run.
It is not a step-by-step guide for reproducing the same results. If you want the commands to run in order,
see the [Quick Start](/getting-started/first-run).
:::

```mermaid
flowchart TD
  P1["フェーズ1: プロダクト企画"] --> P2["フェーズ2: バックログ起票"]
  P2 --> P3["フェーズ3: 実装"]
  P3 --> P4["フェーズ4: レビュー"]
  P4 --> P5["フェーズ5: マージ"]
  P5 --> P6["フェーズ6: Epicロールアップレビュー"]
  P6 -->|新たな問題を発見| P7["フェーズ7: 次サイクルの自動生成"]
  P7 --> P8["フェーズ8: 実装継続"]
  P8 -.->|次のIssueへ| P3

  style P6 fill:#fef3c7,stroke:#f59e0b
  style P7 fill:#fef3c7,stroke:#f59e0b
```

1. **Phase 1: Product Planning (/product:start, full profile)**

    All 23 phases of planning work were completed — from <Tooltip tip="このプロダクトで何を実現したいのかを言葉にしたもの。パイプラインの出発点です。" headline="Vision" cta="用語集で見る" href="/glossary">Vision</Tooltip> and <Tooltip tip="今回やる範囲と、やらない範囲。MoSCoWやRICEスコアで決めます。" headline="Scope" cta="用語集で見る" href="/glossary">Scope</Tooltip> through architecture design.
    This work produced approximately 30 files in the `reports/` folder.
    The product name candidate "EASE" was selected based on the North Star Metric — the key measure of success, defined here as "deal freshness rate" (how up-to-date deal information is kept).
    EASE stands for Effortless, Always-updated, Shared, and Everyone.

2. **Phase 2: Backlog Creation (/architect:export-backlog)**

    12 Issues (1 Epic, 3 Sub-Epics, 8 Issues) were created in GitLab.
    Because the work was done under a personal namespace (a workspace restricted to a single user), GitLab's Epic feature was unavailable, so parent-child relationships were managed using labels and task lists instead.

3. **Phase 3: Implementation (/architect:implement-backlog)**

    Implementation used Java 21, Spring Boot 4.0.7, and PostgreSQL.
    Work proceeded by stacking four branches in sequence (`feature/I1.3.1-...` → `I1.3.2-...` → `I1.1.1-...` → `I1.2.1-...`), implementing all 12 Issues.
    The final test suite contained 35 tests, all passing.

4. **Phase 4: Review (/architect:review-issue)**

    Reviews were conducted in four rounds.
    One blocker (a must-fix issue — [B-1]: missing authorization check on the role elevation operation) was found and fixed.
    Four MRs (merge requests — submissions to bring changes into the main branch) were created, one per reviewed Issue.

5. **Phase 5: Merge (/architect:merge-issue)**

    All four MRs were merged in sequence, completing the Epic's work.
    After merging and pushing, one additional security finding was discovered ([missing presence check on the `changedBy` value], KN-4).
    This was fixed immediately and re-reviewed.

6. **Phase 6: Epic Rollup Review (implement-backlog --review-epic=E1)**

    Two significant findings were discovered that had not been caught during the per-Issue reviews.

    - **[S-1]** The role guard (authorization check) on `PUT /users/{userId}` (the API for updating user information) was inconsistent. The check during user creation had been fixed, but the equivalent check during user update had not.
    - **[S-2]** All 35 tests relied exclusively on mocks (stand-in objects used in place of real ones). Not a single integration test verified the web layer, the persistence layer, or cross-feature interactions.

7. **Phase 7: Next Cycle Auto-Generation (/architect:export-backlog re-run)**

    Based on the problems found in the rollup review, a new Sub-Epic "SE1.4 Identity & Access Management" and 5 associated Issues were filed.
    This is a direct example of review findings becoming the source of the next cycle of work.

8. **Phase 8: Implementation Continues**

    The first Issue in SE1.4 (establishing the Spring Security foundation) was implemented.
    The architectural decision to use HTTP Basic authentication with `User.id` (UUID) as the login identifier was recorded in `decisions.md`.
    After completing the implementation, an Epic-wide consistency check surfaced a new finding: the bootstrap problem — how to create the very first user. This was also recorded.

## Summary: The Problem NexusArchitect Solves

What this end-to-end run demonstrates is that NexusArchitect is not a one-shot code generation tool.
It has a built-in mechanism by which problems found during review directly feed into the next cycle of work.
In practice, the [S-1] and [S-2] findings from the Phase 6 rollup review led directly to the filing of Sub-Epic "SE1.4" in Phase 7.

Each NexusArchitect command plays the following role:

- `export-backlog`: Converts planning artifacts into a machine-readable format (`backlog-manifest.json`)
- `implement-backlog`: Implements with the full Epic context in scope. Uses a lightweight model by default to control cost, and switches to opus (a higher-capability model) for decisions that require deeper judgment
- `review-issue`: Checks not just a single Issue in isolation, but also its consistency with related Issues and the overall Epic. Lessons learned are collected in `review-knowledge.md` and become permanent checklist items for all subsequent reviews
- `merge-issue`: Executes a merge only after passing strict pre-flight checks, and accurately records completion status

In addition, whenever a Sub-Epic is completed, an Epic rollup review is performed.
This review exists to catch problems that per-Issue reviews alone would miss.
In this session, two problems were found for the first time at this stage: "an incomplete role guard fix (creation was fixed but update was not)" and "all tests are mocks with no real integration tests."
Those results then fed directly into the filing of the next Sub-Epic (Phase 7).
This mechanism — where review outcomes generate concrete follow-on work — is the core of NexusArchitect's backlog management.

Problems encountered during this session are documented in [Troubleshooting](/troubleshooting).