Skip to content
arula

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.

Shared intuitionCommon languageEveryday habitsJudgeLearn
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

Goal

Explain why review the build affects confidence in the build.

Complete when

You can name the decision this stage supports and the risk created by skipping it.

How this supports the lab

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?

Builds
Shared intuitionCommon languageEveryday habits
Work stage
JudgeLearn

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

Goal

Identify the accepted evidence and artifacts required for this stage.

Complete when

You can explain why each source is relevant and exclude material that does not affect the work.

How this supports the lab

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.

Builds
Shared intuitionCommon languageEveryday habits
Work stage
JudgeLearn

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

Goal

Study one worked example and identify the judgment behind each step.

Complete when

You can reproduce the reasoning without copying the example’s conclusion.

How this supports the lab

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.

Builds
Shared intuitionCommon languageEveryday habits
Work stage
JudgeLearn
  1. Select one accepted claim and locate its test and code.
  2. Show that the test observes only the response status and misses stored balance state.
  3. State the release claim that the available evidence cannot support.
Explain the reasoning

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

Goal

Separate repository facts from decisions that require human authority.

Complete when

Each question has an accepted answer or remains blocked with a named owner.

How this supports the lab

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.

Builds
Shared intuitionCommon languageEveryday habits
Work stage
JudgeLearn
  • 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

Goal

Use the coding agent to support review the build while retaining control of decisions and evidence.

Complete when

You verified each response before continuing and carried only accepted findings into the artifact.

How this supports the lab

Bounded prompts help investigate and build the balance change while human checks prevent unsupported agent output from entering the evidence chain.

Builds
Shared intuitionCommon languageEveryday habits
Work stage
JudgeLearn

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.
01

Compare specification with code

Why this prompt

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.
Check before continuing

Open every cited location and challenge any claimed match.

02

Compare specification with tests

Why this prompt

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.
Check before continuing

Confirm that balance consistency tests observe both records before and after the request.

03

Compare tests with code

Why this prompt

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.
Check before continuing

Describe the defect that each proposed additional test would reveal.

04

Prepare the release decision

Why this prompt

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.
Check before continuing

Compare the recommendation with your decision and resolve any difference from cited evidence.

Create

Produce the build review and release decision for this repository

Goal

Create a reviewable build review and release decision from accepted inputs.

Complete when

The artifact contains every required field and stays within its stated limit.

How this supports the lab

This artifact records the evidence or decision the next stage needs to move the operation-and-balance change toward a supported release judgment.

Builds
Shared intuitionCommon languageEveryday habits
Work stage
JudgeLearn
  1. Compare each specification claim with the code.
  2. Compare each specification claim with the tests and results.
  3. Compare each test with the code path it claims to exercise.
  4. Record limitations and assign an owner to each remaining risk.
  5. Make an individual release decision and defend it with the trace.
Artifact structureBuild review and release decision

One trace row per material claim, followed by one decision.

  1. Claim ID
  2. Code location
  3. Test and observation
  4. Result
  5. Limitation
  6. Owner
  7. Decision

Challenge

Try to disprove the repository-backed work

Goal

Find a material weakness before the artifact controls later work.

Complete when

Each challenge has evidence, an impact and a recorded response.

How this supports the lab

The challenge tests whether a partial write, duplicate effect, unauthorized operation or unsupported claim could survive the proposed artifact.

Builds
Shared intuitionCommon languageEveryday habits
Work stage
JudgeLearn
Individual transfer check

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 response

Compare your review with the answer key only after recording your release decision.

Revise

Use repository evidence before continuing

Goal

Resolve findings and make an explicit decision about readiness.

Complete when

Every readiness check passes, or the work returns to the section that must change.

How this supports the lab

The gate prevents unresolved balance-consistency risks from flowing into code or supporting a stronger shipping claim than the evidence allows.

Builds
Shared intuitionCommon languageEveryday habits
Work stage
JudgeLearn

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

Goal

Apply the review method to an unfamiliar example without guided prompts.

Complete when

You record a supported release decision before opening the answer key.

How this supports the lab

This tests whether you can detect a specification gap, a weak test and a balance defect without relying on the prepared workflow.

Builds
Shared intuitionCommon languageEveryday habits
Work stage
JudgeLearn

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

Goal

Map this practice to a real codebase, role and delivery decision in your work.

Complete when

You can name the equivalent artifact, evidence, owner and next use in your team.

How this supports the lab

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.

Builds
Shared intuitionCommon languageEveryday habits
Work stage
JudgeLearn
  • 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.