Skip to content
arula

Stage 04 / 15 minutes / Peer audit or individual

Audit the specifications

Find material gaps in the specifications and confirm that each finding is resolved, accepted or escalated.

Shared intuitionCommon languageEveryday habitsDefine
Output
Audit record
Support
Fixed challenge categories
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 audit 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
Shared intuitionCommon languageEveryday habits
Work stage
Define

Independent review can expose a contradiction before generated code makes it harder to see. The audit also tests whether another engineer can use the specifications without relying on the authors’ explanation.

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
Define

Context brief

Review the sources, assumptions and exclusions from stage 1.

Change specification

Review the claims and examples from stage 2.

Test specification

Review the evidence design from stage 3.

Repository sources

Use primary sources to verify disputed claims.

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

Worked example

Audit a precision 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
Define
  1. Compare a two-decimal acceptance rule with the DTO and database field.
  2. Record the gap, the failure it could permit and the source.
  3. Review the author’s revision and close the finding only if the conflict is gone.
Explain the reasoning

An audit finding describes a material effect and cites evidence. “Needs more detail” is not actionable.

The worked example demonstrates one finding and one verified revision.

Decide

Decide the disposition of each repository-backed finding

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
Define
  • Do sign and rounding rules agree across claims and examples?
  • Do ownership and transaction claims have repository support?
  • Can update, patch, delete or direct balance editing break the invariant?
  • Are retry and concurrency claims stronger than the proposed evidence?
  • Do the test specifications challenge every material failure?

Use the agent

Use the agent on this repository

Goal

Use the coding agent to support audit 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
Shared intuitionCommon languageEveryday habits
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

  • Begin a new agent session with the three accepted artifacts.
  • Do not edit the artifacts during the audit.
01

Check traceability

Why this prompt

Every behavior claim needs context and planned evidence.

Audit traceability across the context brief, change specification and test specification. Identify claims without repository context, tests without claims and claims without tests. Cite artifact sections and claim IDs.
Check before continuing

Verify each reported gap directly in the artifacts.

02

Challenge payment behavior

Why this prompt

Focused adversarial review tests the decisions most likely to affect money and ownership.

Try to disprove the specification. Check sign rules, precision, ownership, atomicity, retries, concurrent requests, operation mutation and direct balance changes. For each finding, name the claim, evidence and permitted failure.
Check before continuing

Reject vague findings that do not name a plausible failure.

03

Classify findings

Why this prompt

Severity and required response turn observations into decisions.

Classify each verified finding as blocking, material or editorial. State the change or decision required to close it. Do not rewrite the artifacts or close a finding from an author explanation alone.
Check before continuing

Confirm that classification follows impact, not ease of repair.

04

Verify dispositions

Why this prompt

A finding closes only when the revised artifact resolves its evidence.

Compare the revised artifacts with the audit log. For each finding, report closed, still open or superseded. Cite the exact revision that supports the status.
Check before continuing

Keep any finding open when the cited change does not fully address it.

Create

Produce the audit record for this repository

Goal

Create a reviewable audit record 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
Define
  1. Exchange all three artifacts with another pair. If you are working alone, set them aside for five minutes and return as the reviewer.
  2. Audit each challenge category and cite the affected claim or source.
  3. Classify each finding by impact: blocking, material or editorial.
  4. Return the findings to the authors for a written disposition. If you are working alone, complete a separate author pass.
  5. Verify the revision in a separate reviewer pass before closing a blocking or material finding.
Artifact structureAudit record

One row per distinct finding.

  1. Finding ID
  2. Affected claim
  3. Evidence
  4. Impact
  5. Required response
  6. Disposition
  7. Owner
  8. Verification

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
Define
Artifact authors or separate author pass

Resolve, accept or escalate each finding and cite the resulting change.

Required response

The auditor verifies the change. Disagreement remains open with a named decision owner.

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
Define

Ready to continue when

  • Every blocking and material finding has a verified disposition or named escalation.
  • The specification and test specification agree.
  • Accepted limitations state which release claim they prevent.

If a check fails

  • Rewrite vague findings to include effect and evidence.
  • Reopen a finding when the response explains the issue but does not change the artifact.
  • Use the readiness criteria to resolve process questions. Keep product decisions open for the authorized owner.

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
Define
  • Identify the reviewer who should challenge specification quality before coding begins on your team.
  • Choose where audit findings and dispositions should live in your delivery process.

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