Skip to content
arula

Stage 01 / 15 minutes / Pairs or individual

Derive context

Find out what happens when a user records a credit or debit for a bank account. Identify the code that handles the request, what gets saved, whether the account balance changes, and what the code leaves undecided.

Shared intuitionCommon languageDefine
You will create
A context brief explaining what happens when a credit or debit is submitted.
We will demonstrate
How to trace the amount from the form to the database.
Done when
Your context brief answers three questions: What happens today? What proves it? What still needs a decision?

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 derive context 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 language
Work stage
Define

The issue describes a balance symptom. Before proposing a change, engineers must establish where the request travels, where data changes and what the current tests observe.

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 language
Work stage
Define

Issue

Posting an operation must leave its bank account balance consistent. Failed or rejected requests must change neither record.

REST endpoint

Trace creation, updates and deletion.

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

Domain model

Inspect amount, balance and the account relationship.

src/main/java/io/github/jhipster/sample/domain/Operation.java

Related entity

Inspect the independently editable balance.

src/main/java/io/github/jhipster/sample/domain/BankAccount.java

DTO and mapper

Follow the request representation into the persisted entity.

src/main/java/io/github/jhipster/sample/service/mapper/OperationMapper.java

Bank account endpoint

Find the separate create, update, patch and delete paths for balance records.

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

API security

Distinguish authenticated API access from account ownership enforcement.

src/main/java/io/github/jhipster/sample/config/SecurityConfiguration.java

React form

Find the user input and account selection.

src/main/webapp/app/entities/operation/operation-update.tsx

Existing tests

Identify what the integration tests observe.

src/test/java/io/github/jhipster/sample/web/rest/OperationResourceIT.java

Worked example

Trace the amount field from the form to persistence

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 language
Work stage
Define
  1. Find where the React form collects the amount and creates the request object.
  2. Follow the request into OperationDTO and the mapper.
  3. Read createOperation and identify the only repository write.
Explain the reasoning

For each source, state the fact it establishes. Do not treat a class name, annotation or passing test as proof of behavior it does not observe.

The worked example stops after this one field. You trace the remaining behavior.

Decide

Separate repository facts from product decisions

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 language
Work stage
Define
  • Which files determine operation creation and balance behavior?
  • Which files provide useful background but do not affect this change?
  • Which statements are observed facts, and which are assumptions?
  • What product rules cannot be derived from the repository?

Use the agent

Use the agent on this repository

Goal

Use the coding agent to support derive context 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 language
Work stage
Define

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

  • Paste the issue exactly as written. Do not add a solution.
  • Choose one request entry point to trace first.
  • Create context-brief.md for accepted findings.
01

Trace one request path

Why this prompt

Begin with a narrow question so you can inspect the evidence before the search expands.

Read this issue:
[paste the issue]

Trace operation creation from the React form through the API to persistence. Use repository sources only. Cite each file and symbol. Separate observed facts from inferences. Do not propose changes.
Check before continuing

Open each citation. Confirm that the named symbol exists and supports the statement.

02

Trace the related state

Why this prompt

A request trace alone does not show whether operation and balance state can diverge.

Using the verified request trace, find where BankAccount balance is read or changed. Identify transaction boundaries and ownership checks on the create path. Cite each file and symbol. Report missing behavior as a finding, not as a requirement.
Check before continuing

Confirm that the response distinguishes code that exists from behavior the issue may require.

03

Find competing mutation paths

Why this prompt

Other write paths can break a rule that appears sound on the create path.

Search for every path that can create, update or delete an Operation or directly change BankAccount balance. For each path, cite the entry point and persistence call. State whether existing tests observe the balance effect. Do not infer product policy.
Check before continuing

Search the repository yourself for Operation save and delete calls. Add any omitted paths.

04

Assemble the context brief

Why this prompt

Synthesis turns verified findings into a small artifact that the next stage can use.

Draft context-brief.md from the findings I accepted. Include the current request path, related state, transaction boundary, ownership checks, mutation paths, relevant tests and repository constraints. Preserve file and symbol citations. End with exclusions, inferences and questions the repository cannot answer.
Check before continuing

Remove any statement you did not verify or mark it as an inference.

05

Audit the brief

Why this prompt

A separate pass catches unsupported claims and context gathered without a clear use.

Audit context-brief.md against the repository. List unsupported statements, missing sources, irrelevant sources and facts stated as inferences or inferences stated as facts. Do not rewrite the brief. Return findings with exact citations.
Check before continuing

Resolve each finding in the artifact and record rejected findings with a reason.

Create

Produce the context brief for this repository

Goal

Create a reviewable context brief 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 language
Work stage
Define
  1. Trace the selected account from the form to the stored relationship.
  2. Locate the transaction boundary and both repositories.
  3. Inspect update, partial-update and delete paths for operations and bank accounts.
  4. Read the existing Java, React and Cypress tests. Record what each test observes.
  5. Write the context brief and link every material fact to a source.
Artifact structureContext brief

One page plus a source list.

  1. Current request path
  2. Observed behavior
  3. Relevant sources
  4. Excluded sources and reasons
  5. Assumptions
  6. Open questions

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 language
Work stage
Define
Peer review or self-check

Give the brief to another pair. If you are working alone, close the repository and explain the behavior using only the brief. Mark every unsupported statement and missing source.

Required response

The authors add evidence, relabel an inference or remove the statement.

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 language
Work stage
Define

Ready to continue when

  • A reviewer can reconstruct the current operation flow from the cited sources.
  • The brief distinguishes facts, assumptions and product questions.
  • Exclusions have reasons tied to the issue.

If a check fails

  • Return to the first unsupported statement and locate a primary source.
  • If the repository cannot answer a question, record it instead of guessing.
  • Use the source list on this page only after recording where you looked and what you expected to find.

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 language
Work stage
Define
  • Name the equivalent request entry point, persistence boundary and tests in one service you maintain.
  • Identify one generated or framework area you would exclude from the first context pass.

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