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.
- 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
Explain why derive context 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?
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
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.
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.javaDomain model
Inspect amount, balance and the account relationship.
src/main/java/io/github/jhipster/sample/domain/Operation.javaRelated entity
Inspect the independently editable balance.
src/main/java/io/github/jhipster/sample/domain/BankAccount.javaDTO and mapper
Follow the request representation into the persisted entity.
src/main/java/io/github/jhipster/sample/service/mapper/OperationMapper.javaBank account endpoint
Find the separate create, update, patch and delete paths for balance records.
src/main/java/io/github/jhipster/sample/web/rest/BankAccountResource.javaAPI security
Distinguish authenticated API access from account ownership enforcement.
src/main/java/io/github/jhipster/sample/config/SecurityConfiguration.javaReact form
Find the user input and account selection.
src/main/webapp/app/entities/operation/operation-update.tsxExisting tests
Identify what the integration tests observe.
src/test/java/io/github/jhipster/sample/web/rest/OperationResourceIT.javaWorked example
Trace the amount field from the form to persistence
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.
- Find where the React form collects the amount and creates the request object.
- Follow the request into OperationDTO and the mapper.
- Read createOperation and identify the only repository write.
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
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.
- 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
Use the coding agent to support derive context 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
- 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.
Trace one request path
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.Open each citation. Confirm that the named symbol exists and supports the statement.
Trace the related state
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.Confirm that the response distinguishes code that exists from behavior the issue may require.
Find competing mutation paths
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.Search the repository yourself for Operation save and delete calls. Add any omitted paths.
Assemble the context brief
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.Remove any statement you did not verify or mark it as an inference.
Audit the brief
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.Resolve each finding in the artifact and record rejected findings with a reason.
Create
Produce the context brief for this repository
Create a reviewable context brief 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.
- Trace the selected account from the form to the stored relationship.
- Locate the transaction boundary and both repositories.
- Inspect update, partial-update and delete paths for operations and bank accounts.
- Read the existing Java, React and Cypress tests. Record what each test observes.
- Write the context brief and link every material fact to a source.
One page plus a source list.
- Current request path
- Observed behavior
- Relevant sources
- Excluded sources and reasons
- Assumptions
- Open questions
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.
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 responseThe authors add evidence, relabel an inference or remove the statement.
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
- 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
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.
- 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.