Skip to content
arula

Before the lab / Preparation

Prepare the pinned JHipster repository

Establish a working repository and a visible agent baseline before the 120-minute lab begins.

Set up
Pinned source and repository instructions
Record
Repository and visible session state
Verify
Tests and local application

Repository for this lab jhipster/jhipster-sample-app-react at 8c9d248 .

Set up the repository

Goal

Create a reproducible workspace at the revision used for this lab.

Complete when

The baseline checks pass, the application opens and one approved coding agent runs from the repository root.

How this supports the lab

First confirm that the unchanged application builds, passes its tests, and runs. If something breaks later, you can tell whether the problem already existed or was introduced by your change.

Finish this page before Stage 1

You are ready when the pinned repository checks pass, the application opens and your coding agent confirms which repository instructions it loaded.

You can complete the lab on your own. You need Git, Java 21 and a coding agent you are authorized to use. The project wrapper installs its pinned Node and npm versions. The development profile uses local H2 and does not require an external service account.

git clone https://github.com/jhipster/jhipster-sample-app-react.git
cd jhipster-sample-app-react
git checkout 8c9d248a863ffb2034f72425d9325e1669472670
git switch -c lab-3-balance
./mvnw verify
./npmw test
git clone

Downloads the public repository. Run this once in the directory where you keep development projects.

cd

Moves the terminal into the repository. Run all remaining commands from this directory.

git checkout

Selects the exact revision used to design the lab so source paths and baseline behavior match the instructions.

git switch -c

Creates a local branch for your specifications, tests and implementation.

./mvnw verify

Uses the project’s Maven wrapper to compile the application and run its configured verification checks.

./npmw test

Uses the project’s npm wrapper to run linting and the Vitest front-end suite with coverage.

Open your coding agent in the repository

Open a new terminal at the checked-out jhipster-sample-app-react root and start one approved tool there. The sample application does not require a vendor account. Your coding agent requires access provided by you or your organization.

Load the repository instructions

Use one root instruction file written for this pinned JHipster application. It records how to work in the repository without supplying the balance analysis or product decisions that the lessons require participants to derive.

View the copy-ready repository instructions and adapter
# JHipster Lab 3 repository instructions

## Repository baseline

- Work from jhipster/jhipster-sample-app-react at commit 8c9d248a863ffb2034f72425d9325e1669472670.
- This repository uses Java 21, Spring Boot, React and TypeScript.
- Use the checked-in Maven and npm wrappers.
- Baseline verification: ./mvnw verify and ./npmw test.

## Working rules

- Inspect repository evidence before making claims.
- Separate verified facts, inferences, assumptions, and unresolved decisions.
- Cite facts with file paths and symbols or line numbers.
- Do not modify files unless the current task explicitly authorizes implementation.
- Preserve unrelated working-tree changes.
- Do not delete, weaken, or bypass tests to obtain a passing result.
- Ask before adding dependencies, accessing external systems, or using destructive Git commands.

## Lab boundary

- Keep investigation and changes within the bank-account and operation journey unless an accepted artifact expands the scope.
- Do not run JHipster regeneration.
- Do not change unrelated authentication, administration, deployment or production-database configuration.

## Reporting

- Record commands, exit status, and relevant output.
- Never report a check as passing unless it was executed.
- State what the available evidence does not establish.

Save the shared content as AGENTS.md at the cloned repository root. If an agent expects a different filename, use a thin adapter rather than rewriting it. For example, Claude Code can import that file from CLAUDE.md:

# CLAUDE.md

@AGENTS.md

The repository instructions are provider-neutral. These Codex instruction-discovery details and Claude Code project-instructions details explain how each tool loads them.

Keep the root file small. Put the current outcome and accepted repository artifacts in the stage task brief; put occasional multi-step procedures in the selected tool’s reusable workflow mechanism.

Instruction files guide agent behavior; they do not enforce policy. Put restrictions that must not be bypassed in permissions, sandbox rules, hooks, CI or organization controls.

Add these files before feature work

The facilitator should distribute AGENTS.md and the required adapter with the lab. When working directly from the pinned upstream repository, commit only those course files as the first commit on lab-3-balance, then begin the feature work so later changes remain reviewable.

Capture the repository and session baseline

A new conversation does not guarantee an empty context. Before Stage 1, create one preflight record that begins with the actual repository state, then records the user-visible agent conditions that could affect work.

Verify the repository

Record pwd, git rev-parse HEAD, git branch --show-current and git status --short. The revision must match the lab pin before course-only setup commits are added.

Start consistently

Open a new, non-resumed session from this repository root for each stage. Use one facilitator-selected memory profile—disabled where supported, or enabled and disclosed—for every participant.

Inspect native state

Use the selected agent’s status, context, instruction, memory, tool and permission views when available. Ask it to summarize the active repository guidance without modifying files, then confirm that AGENTS.md and any adapter loaded.

Qualify the evidence

Label each preflight item observed, self-reported or not exposed. Record the inspection method and relevant result; never claim that unexposed context is absent.

View the preflight record template
# JHipster Lab 3 preflight

- Recorded: [date, time and timezone]
- Repository: jhipster/jhipster-sample-app-react
- Lab source revision: 8c9d248a863ffb2034f72425d9325e1669472670
- Working revision: [git rev-parse HEAD]
- Repository root: [pwd]
- Branch: [git branch --show-current]
- Working tree: [git status --short result]
- Agent and version: [value]
- Model and settings: [value or not exposed]
- Session: new, not resumed
- Repository instructions: [loaded files and adapters]
- Additional visible context: [source and scope]
- Memory profile: [disabled or enabled and disclosed]
- Tools and permissions: [summary or not exposed]

## Evidence

| Claim | Inspection method | Result | Status |
| --- | --- | --- | --- |
| Pinned source established | git rev-parse HEAD | [result] | observed |
| Repository instructions loaded | [native view or agent report] | [result] | [observed / self-reported] |

## Limits

- This record covers user-visible and tool-reported context only.
- It does not establish that unexposed context is absent.

Prefer text that another participant can inspect or rerun. Use screenshots only for state that cannot be captured accurately as text, and do not record credentials, private instruction contents or unrelated personal configuration.

Commission work against repository evidence

Each stage task brief starts from this repository and the accepted artifact produced by the prior stage. Describe the outcome and controls, then let the agent inspect the pinned source rather than prescribing an invented implementation path:

  1. Mode: investigate, propose, act or review—including which workspace or external changes are allowed.
  2. Outcome: the repository artifact or decision the task must produce and why it matters.
  3. Accepted context: the pinned revision, issue and approved artifacts from earlier stages.
  4. Boundaries: allowed areas, prohibited actions, product decisions and external side effects.
  5. Success criteria: observable conditions that must be true before the work is complete.
  6. Verification: repository sources or commands that must support each material claim.
  7. Output and stop conditions: the required record and conditions that require returning to an earlier artifact or owner.
Example Stage 1 task brief

Mode: investigate only; do not modify files. Outcome: explain the current operation journey in jhipster-sample-app-react. Accepted context: the issue and commit 8c9d248. Boundaries: inspect the operation and bank-account journey without deciding product policy. Success: another engineer can reconstruct the path. Verification: cite repository paths and symbols and separate facts from inferences. Output: context-brief.md. Stop if the revision or baseline differs from the preflight record.

Keep the artifacts in charge

Start a new agent session for each stage. Give it the accepted artifact from the prior stage. Do not rely on hidden context from an earlier chat. Within a stage, keep the session open while you run its prompt sequence.

Confirm the runnable baseline

Run the application in two terminals when you need the UI:

./npmw run backend:start
./npmw run start
backend:start

Starts Spring Boot on port 8080 with the development profile and in-memory H2 database. Leave it running.

start

Starts the Vite front end on port 9000 and proxies API requests to the back end. Leave it running in a second terminal.

Confirm the baseline

Open http://localhost:9000 and sign in with admin/admin or user/user. Both verification commands should exit successfully. Record the command, exit status and error output for any failure. Resolve baseline failures before changing code.