Change requests on an existing project

The workflow

1. Check the generator. The skill's first step on an existing project: does build.gradle have an elasticore { } block with architecture = 'hexagonal' or 'ddd'? On the 2.x path the agent does not use @access, states:, @compute ... - it tells you what they would need, since moving to the rule engine is your decision.

2. Ask for the change in business terms - or hand it to the modeler:

   Use the elasticore:modeler agent: members can review an item once - rating 1 to 5, a text up to 1000 characters, the time set by the server; only the writer edits it.

   The modeler finds the model and the generator, looks the constructs up in the project's own guides, makes the smallest DSL change, generates and compiles until there is no warning and no error, and returns a change report.

3. Generate and read the output: /elasticore:generate runs compileJava (never -Pforce) and explains the summary line, every DSL warning with its YAML fix, and every hand-edited generated file with where its edit belongs.

4. Report: /elasticore:change-report (default: what is not committed yet; or a git range) reads the DSL diff and writes what changed for the business - stored data, who may do what, the lifecycle, derived values, the API - and what needs a decision.

5. Review: /elasticore:review hands the change to the reviewer agent - hand edits to generated files, DSL the guides or the generator do not know, generated code out of step with the DSL, roles that gain or lose access. It only reads; /elasticore:review full also builds.

The hooks hold the line throughout: no edits to generated files, no -Pforce without you, and no finishing before a successful build has generated and compiled the DSL change.

A change report

## What changes for the business

**Review (new)**
- Stores: rating 1-5, text up to 1000 characters, written at (set by the server)
- Who may: members write; only the writer changes it
- API: /api/shop/review - create, read, search, update, delete

## Needs a decision

- ...

## Checked

- Generator: 3.0 rule engine, architecture hexagonal
- Generation: N written / N unchanged / N skipped / 0 failed, DSL validation warnings: none
- Compile and tests: ./gradlew build - passed
- Hand-written code: ...

This is the shape of the kit's template (references/change-report.md); the lines are illustrative. The report is written in the user's language. What goes under Needs a decision:

DSL change	Why
@access(...) wider, @owner removed	more people see or change data
a field removed or renamed	its column and API field disappear; stored values may be lost
a type narrowed (string(n), money(p.s))	existing values may no longer fit
a state or move removed from states:	records in that state may get stuck
@expose removed or reduced	clients that call the API break
an @id or @genid changed	keys and every reference to them change
@password, @login changed	sign-in changes for every user

What a real change request showed

The kit's pet store benchmark gave three finished shops (Java hexagonal, Java DDD, Kotlin hexagonal) a change request - stock, reviews, a courier API, BI measures, Korean error messages - with Claude Code and the kit. Scores 20, 19.5 and 20 of 20 in 13 to 14 minutes; regenerating each changed project wrote nothing and found no hand-edited generated file. What the agents still wrote by hand or looked up became ElastiCORE fixes and quick-reference entries: PUT /batch through update(), @updatable(false) on references, one language per error answer, PortCallException (502), typescriptClient = true, case-insensitive like. The full story: Evolving a generated project.

Tips

• On Windows build with ./gradlew.bat, from Git Bash too - the Unix script does not return to the tool when it starts a Gradle daemon.
• Start the server in one tool call and call it in the next.
• A project with a TypeScript client: typescriptClient = true, or ./gradlew elcore3ts after each change.
• Look for * LOAD ERROR: after every DSL change - a : in a -- description breaks the file.