Skip to content
arula

Stage 05 / 10 minutes / Pairs or individual

Plan from the specifications

Produce the smallest ordered plan that covers each accepted claim and its evidence.

Common languageEveryday habitsPlan
Output
Implementation plan
Support
One claim-to-change example
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 plan from the specifications 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
Common languageEveryday habits
Work stage
Plan

A plan should expose scope and sequence before code is generated. It should also reveal claims with no implementation step, edits with no accepted purpose and tests that run too late to guide the work.

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
Common languageEveryday habits
Work stage
Plan

Audited specifications

Use only accepted claims, evidence and limitations.

REST resource

Locate the current transaction and API seams.

src/main/java/io/github/jhipster/sample/web/rest/OperationResource.java

Account repository

Locate account persistence.

src/main/java/io/github/jhipster/sample/repository/BankAccountRepository.java

Operation repository

Locate operation persistence and relationship loading.

src/main/java/io/github/jhipster/sample/repository/OperationRepository.java

Bank account resource

Account for direct balance mutation paths when the accepted specification requires them.

src/main/java/io/github/jhipster/sample/web/rest/BankAccountResource.java

React operation flow

Locate request and result handling.

src/main/webapp/app/entities/operation/operation.reducer.ts

Worked example

Map one atomicity claim to a test and code seam

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
Common languageEveryday habits
Work stage
Plan
  1. Select the atomic creation claim and its Java integration test.
  2. Name the boundary that must own both state changes.
  3. Order the failing test before the implementation step.
Explain the reasoning

A plan names the purpose and evidence for a change. A file list alone does not show whether the plan covers the specification.

The worked example does not propose the full architecture.

Decide

Choose the repository seams and stop conditions

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
Common languageEveryday habits
Work stage
Plan
  • Which boundary should coordinate the operation and balance changes?
  • Which test should fail before each behavior changes?
  • Does the accepted specification require a schema or response change?
  • Which generated files must remain untouched?
  • Where should the team stop and revise the specification?

Use the agent

Use the agent on this repository

Goal

Use the coding agent to support plan from the specifications 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
Common languageEveryday habits
Work stage
Plan

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

  • Use only audited claims and test specifications.
  • Set the largest change a reviewer can assess in one increment.
01

Map the work

Why this prompt

The first pass exposes missing coverage before ordering implementation.

Map every accepted claim to its test change and smallest code seam. Identify claims with no implementation work and proposed edits with no accepted claim. Do not order the work yet.
Check before continuing

Trace every row backward to a claim and forward to an observable test result.

02

Order the increments

Why this prompt

Evidence-first ordering shows that existing behavior fails before code changes make it pass.

Order the mapped work into reviewable increments. Put the focused failing test before each behavior change. Give every increment a claim ID, allowed files, verification command and stop condition.
Check before continuing

Split an increment if it changes more than one independently reviewable behavior.

03

Add risk and recovery

Why this prompt

A plan must show how a failed increment is contained or reversed.

For each increment, state its main risk, evidence limit and rollback or recovery step. Flag generated files and unrelated changes that must remain outside the boundary.
Check before continuing

Confirm that each recovery step can be performed without guessing.

04

Audit the plan

Why this prompt

A plan should expose specification gaps instead of solving them silently.

Audit the plan for uncovered claims, unclaimed edits, oversized steps, vague commands and decisions made outside the accepted specification. Return findings only.
Check before continuing

Resolve findings in the plan or return the work to the specification stage.

Create

Produce the implementation plan for this repository

Goal

Create a reviewable implementation plan 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
Common languageEveryday habits
Work stage
Plan
  1. Create a plan row for each accepted claim.
  2. Link the claim to a test, implementation seam and verification command.
  3. Order work in small test-and-behavior increments.
  4. Record risks, rollback steps and explicit exclusions.
  5. Check the plan for unlinked edits and uncovered claims.
Artifact structureImplementation plan

Six to 10 ordered steps.

  1. Step
  2. Claim IDs
  3. Test change
  4. Code seam
  5. Verification
  6. Risk
  7. Rollback or recovery

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
Common languageEveryday habits
Work stage
Plan
Peer review or self-check

Ask another pair to find one uncovered claim, one edit without an accepted purpose or one step that assumes its result. If you are working alone, trace the plan backward from each edit and forward from each claim.

Required response

The authors update the sequence, narrow the scope or return to the specification.

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
Common languageEveryday habits
Work stage
Plan

Ready to continue when

  • Every plan step links to an accepted claim and evidence.
  • Every accepted claim appears in the plan.
  • The sequence can produce useful evidence before the full build is complete.

If a check fails

  • Remove edits that do not support a claim.
  • Split steps that change several behaviors before verification.
  • Return to stage 2 or 3 when the plan exposes a missing decision or test.

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
Common languageEveryday habits
Work stage
Plan
  • Compare this plan structure with your team’s issue or pull request template.
  • Name one field you would add to make claim-to-test traceability routine.

Record your answer. The lab is complete only when you can name the equivalent practice, artifact and evidence in your work.