Stage 07 / 20 minutes / Individual
Review the build
Decide whether to ship, revise or stop by comparing the accepted claims, tests, code and observed results.
- Output
- Build review and release decision
- Support
- No stage prompts during final check
- Continue when
- All readiness checks pass
Repository for this lesson jhipster/jhipster-sample-app-react at 8c9d248 . All source links, commands and observations refer to this pinned revision.
Orient
Why this stage matters
Explain why review the build affects confidence in the build.
You can name the decision this stage supports and the risk created by skipping it.
This ties the stage to the lab’s central question: Does the evidence show that posting an operation and changing its account balance form one safe, reviewable outcome?
Passing checks establish only what they observed. The reviewer must find mismatches, limit the release claim to the available evidence and identify the person who owns each remaining risk.
Inputs
Use repository sources and accepted artifacts
Identify the accepted evidence and artifacts required for this stage.
You can explain why each source is relevant and exclude material that does not affect the work.
These sources establish what the repository does when operation and balance records can be changed independently. Later claims and tests must trace back to this evidence.
Accepted artifacts
Use the final context, specifications, audit and plan.
Build
Review the complete diff and deviation log.
Evidence
Review actual command results and test observations.
Unseen patch
Use the review case provided on this page for the independent transfer check.
Worked example
Review one seeded mismatch
Study one worked example and identify the judgment behind each step.
You can reproduce the reasoning without copying the example’s conclusion.
The example models one part of the operation-and-balance problem. You apply the same reasoning to the remaining paths and produce evidence another engineer can review.
- Select one accepted claim and locate its test and code.
- Show that the test observes only the response status and misses stored balance state.
- State the release claim that the available evidence cannot support.
The reviewer does not count tests or restate the implementation. The reviewer checks whether the code and evidence support each accepted claim.
The worked example models the comparison. The final patch removes the prompts.
Decide
Make the release decision from repository evidence
Separate repository facts from decisions that require human authority.
Each question has an accepted answer or remains blocked with a named owner.
The repository cannot decide credit, debit, retry, ownership or mutation policy. Those decisions define what balance consistency means and what can be judged safe to ship.
- Does the code implement every accepted claim at the correct boundary?
- Could the tests pass while the operation and balance diverge?
- Do transaction, retry and ownership claims exceed the evidence?
- Which existing CRUD paths remain unsafe or untested?
- Should the result ship, return for revision or stop?
Use the agent
Use the agent on this repository
Use the coding agent to support review the build while retaining control of decisions and evidence.
You verified each response before continuing and carried only accepted findings into the artifact.
Bounded prompts help investigate and build the balance change while human checks prevent unsupported agent output from entering the evidence chain.
These are task patterns for the pinned JHipster source, not answer scripts. Replace every bracketed field with accepted repository work. Open every cited path at the pinned revision and review each response before continuing. If you cannot supply a field, return to the earlier artifact.
Decide before prompting
- Open a new agent session with accepted artifacts, the full diff and command results.
- Make your own release decision before asking for a recommendation.
Compare specification with code
This comparison finds missing, extra and incorrectly implemented behavior.
Review the full diff against the accepted change specification. Do not change code. For each claim, cite the implementing location and report satisfied, violated or not implemented. List code changes with no accepted claim.Open every cited location and challenge any claimed match.
Compare specification with tests
This comparison shows whether the evidence covers the accepted behavior.
Review the tests against the accepted claims and test specification. For each claim, cite the observing test and the state it checks. Identify missing cases and assertions that cannot prove the claim.Confirm that balance consistency tests observe both records before and after the request.
Compare tests with code
This comparison reveals code paths that the tests do not execute or distinguish.
Review changed code against the test suite and command results. Identify unexecuted branches, untested mutation paths and tests that could pass with a plausible defect. State evidence limits.Describe the defect that each proposed additional test would reveal.
Prepare the release decision
A release judgment must connect claims, evidence, limits and accountable owners.
Using only verified review findings, recommend ship, revise or stop. List the supporting evidence, remaining risks, evidence limits and owner for each risk. Do not treat a passing local build as production proof.Compare the recommendation with your decision and resolve any difference from cited evidence.
Create
Produce the build review and release decision for this repository
Create a reviewable build review and release decision from accepted inputs.
The artifact contains every required field and stays within its stated limit.
This artifact records the evidence or decision the next stage needs to move the operation-and-balance change toward a supported release judgment.
- Compare each specification claim with the code.
- Compare each specification claim with the tests and results.
- Compare each test with the code path it claims to exercise.
- Record limitations and assign an owner to each remaining risk.
- Make an individual release decision and defend it with the trace.
One trace row per material claim, followed by one decision.
- Claim ID
- Code location
- Test and observation
- Result
- Limitation
- Owner
- Decision
Challenge
Try to disprove the repository-backed work
Find a material weakness before the artifact controls later work.
Each challenge has evidence, an impact and a recorded response.
The challenge tests whether a partial write, duplicate effect, unauthorized operation or unsupported claim could survive the proposed artifact.
Review the patch provided on this page. It contains one specification gap, one weak test and one code defect. Do not use the stage prompts.
Required responseCompare your review with the answer key only after recording your release decision.
Revise
Use repository evidence before continuing
Resolve findings and make an explicit decision about readiness.
Every readiness check passes, or the work returns to the section that must change.
The gate prevents unresolved balance-consistency risks from flowing into code or supporting a stronger shipping claim than the evidence allows.
Ready to continue when
- The decision addresses every material claim.
- Each conclusion cites code and executed evidence.
- Limitations prevent unsupported production claims.
- The participant identifies all three defects in the unseen patch.
If a check fails
- Return a claim without code or evidence for revision.
- Narrow a conclusion that relies on an untested environment or path.
- Repeat the unseen review after feedback when a material defect is missed.
Independent transfer check
Review this new change without the stage prompts
Apply the review method to an unfamiliar example without guided prompts.
You record a supported release decision before opening the answer key.
This tests whether you can detect a specification gap, a weak test and a balance defect without relying on the prepared workflow.
Set a 10-minute timer. Copy your findings and release decision into the build review before opening the answer key.
Specification excerpt
C-1: Add the signed operation amount to the current account balance.
C-2: Save the operation and balance in one transaction.
C-3: Allow only the account owner to post an operation.
C-4: Reject updates and deletion after an operation is posted.Implementation excerpt
var account = bankAccountRepository.findById(operationDTO.getBankAccount().getId())
.orElseThrow();
assertCurrentUserOwns(account);
var newBalance = account.getBalance().subtract(operationDTO.getAmount());
account.setBalance(newBalance);
bankAccountRepository.save(account);
operationRepository.save(operationMapper.toEntity(operationDTO));Test excerpt
restOperationMockMvc.perform(post("/api/operations")
.contentType(MediaType.APPLICATION_JSON)
.content(om.writeValueAsBytes(operationDTO)))
.andExpect(status().isCreated());
assertThat(operationRepository.findAll()).hasSize(databaseSizeBeforeCreate + 1);Reveal the answer key after recording your decision
Specification gap
The specification does not define how the system recognizes or handles a repeated request. It cannot support an idempotency or exactly-once claim.
Code defect
The code subtracts the signed amount. A debit of -25.00 increases the balance by 25.00, which violates C-1.
Weak test
The test checks the response and operation count. It never observes the account balance, ownership, atomicity or mutation rules.
Supported decision
Revise or stop. The code violates an accepted claim, and the test cannot reveal the defect.
Transfer
Apply the practice to your work
Map this practice to a real codebase, role and delivery decision in your work.
You can name the equivalent artifact, evidence, owner and next use in your team.
The lab succeeds when you can use the same evidence chain to judge an AI-assisted change in a production codebase, beyond this sample’s operation-and-balance problem.
- Apply the review trace to a current or recent pull request after the lab.
- Record what changed in the release decision because of the review.
- Share the resulting work sample with the course team for the delayed transfer check.
Record your answer. The lab is complete only when you can name the equivalent practice, artifact and evidence in your work.