Tutorial: EASE
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.
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.
Phase 1: Product Planning (/product:start, full profile)
All 23 phases of planning work were completed — from VisionVisionこのプロダクトで何を実現したいのかを言葉にしたもの。パイプラインの出発点です。用語集で見る and ScopeScope今回やる範囲と、やらない範囲。MoSCoWやRICEスコアで決めます。用語集で見る 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.
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.
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.
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.
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.
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.
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.
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 judgmentreview-issue: Checks not just a single Issue in isolation, but also its consistency with related Issues and the overall Epic. Lessons learned are collected inreview-knowledge.mdand become permanent checklist items for all subsequent reviewsmerge-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.