Can you implement this feature cleanly?

Implement the optional escalationReason filter in the case search API.

Before editing:
- Inspect existing enum-based search filters.
- Identify the closest test pattern.
- Summarize the files you plan to modify.

Scope:
- Allowed: request DTO, predicate builder, API/repository tests.
- Not allowed: database schema, response shape, pagination, authorization rules.

Behavior:
- No filter: existing behavior unchanged.
- Valid filter: return only matching cases.
- Invalid filter: use existing validation error shape.
- Visibility rule: jurisdiction restrictions still apply.

Verification:
- Add tests that fail before implementation and pass after.
- Run ./gradlew test --tests '*CaseSearch*'.

Output:
- Plan.
- Diff summary.
- Tests added/updated.
- Verification result.
- Assumptions and risks.

1. Role / operating mode
2. Task intent
3. Current state
4. Expected behavior
5. Scope boundaries
6. Constraints and invariants
7. Relevant context
8. Workflow instructions
9. Verification instructions
10. Output format
11. Stop conditions

Operate as a conservative senior engineer making a small, reviewable production change. Prefer existing project patterns over introducing new abstractions. Ask/stop if the task requires a public contract change outside the stated scope.

Intent: reduce manual analyst filtering by adding server-side filtering for escalation reason while preserving existing search semantics.

Current state: case search supports status and date range filters. Escalation reason is stored on the current case escalation record but is not exposed as a search request field.

Expected behavior:
- escalationReason absent: no behavior change.
- escalationReason present: AND-composed with existing filters.
- invalid value: same validation error format as status.

Allowed changes:
- CaseSearchRequest
- CaseSearchPredicateBuilder
- CaseSearchControllerIT
- OpenAPI generated output if generated by existing script

Do not change:
- database schema
- response schema
- authorization policy
- pagination or sorting defaults

Invariants:
- CaseVisibilityPolicy must remain mandatory for every search query.
- Soft-deleted cases must never be returned.
- Filters compose with AND semantics.
- Validation errors must use ProblemDetail format.

Workflow:
1. Inspect existing status filter implementation and tests.
2. Write a short plan.
3. Implement the smallest diff.
4. Add tests.
5. Run the relevant tests if tool access allows.
6. Summarize results and unresolved risks.

Verification:
- New test must fail before implementation if practical.
- Run ./gradlew test --tests '*CaseSearch*'.
- If tests cannot be run, explain why and provide the exact command for the reviewer.

Output format:
- Plan: 3-5 bullets
- Changed files: path + reason
- Tests: added/updated + behavior covered
- Verification: command + result
- Risks: assumptions, follow-ups, skipped checks

Stop if:
- The change requires a database migration.
- The existing code has no escalationReason source field.
- Authorization behavior is unclear.
- Tests fail for reasons unrelated to this task.

Inspect the repository to understand how case search filters are implemented.

Find:
- request DTO for search filters,
- predicate/query builder,
- validation error handling,
- closest tests for enum filters,
- command used to run relevant tests.

Do not edit files. Return:
- files found,
- current implementation pattern,
- likely files to change,
- open questions or risks.

Using the discovered files, propose a minimal implementation plan.

Plan requirements:
- Max 5 steps.
- Each step must name files likely to change.
- Keep public API response unchanged.
- Include tests for default behavior, valid filter, invalid filter, and visibility composition.
- Do not implement yet.

Compare two implementation options:
A. Add escalationReason directly to existing predicate builder.
B. Introduce a reusable enum filter abstraction.

Evaluate against:
- diff size,
- consistency with existing patterns,
- testability,
- risk of over-abstraction,
- future extensibility.

Recommend one option. Do not edit code.

Implement the approved plan.

Rules:
- Keep diff minimal.
- Follow existing status filter pattern.
- Add tests before or alongside implementation.
- Do not refactor unrelated code.
- Do not change generated files manually.

After editing, run the relevant tests if possible.

Verify the current diff.

Check:
- Does it satisfy each acceptance criterion?
- Are all invariants preserved?
- Do tests cover both positive and negative behavior?
- Are there changed files outside scope?
- What commands were run and what were the results?

Do not make new changes unless verification finds a direct defect in the diff.

Review your own diff as a skeptical senior reviewer.

Focus on:
- behavior correctness,
- backward compatibility,
- authorization/security,
- test quality,
- unnecessary abstraction,
- edge cases,
- hidden coupling,
- migration or rollout risk.

Return blocking issues, non-blocking suggestions, and what you would approve.

Prepare a PR summary.

Include:
- Problem solved.
- Implementation approach.
- Files changed by category.
- Tests added/updated.
- Verification commands and results.
- Risk assessment.
- Rollback considerations if relevant.

Do not oversell. Mention checks that were not run.

Implement [feature] with the smallest reviewable diff.

Intent:
[why this feature exists]

Expected behavior:
- [case 1]
- [case 2]
- [case 3]

Scope:
Allowed:
- [files/modules]

Not allowed:
- [dangerous areas]

Invariants:
- [domain/security/contract rule]

Existing pattern:
Follow [test/class/module] unless you find a strong reason not to.

Verification:
- Add tests for [behaviors].
- Run [commands].

Output:
- Plan before editing.
- Diff summary.
- Verification result.
- Risks.

Fix the bug described below by changing product code, not weakening tests.

Symptom:
[observable failure]

Reproduction:
[command / test / steps]

Expected behavior:
[correct behavior]

Constraints:
- Do not remove assertions.
- Do not skip or disable tests.
- Do not broaden matchers unless the expected behavior is wrong and you explain why.
- Keep the fix close to the root cause.

Workflow:
1. Reproduce or inspect the failing test/log.
2. Build a hypothesis tree.
3. Identify the root cause.
4. Make the smallest fix.
5. Add regression test if missing.
6. Verify.

Perform a behavior-preserving refactor.

Objective:
[refactor target]

Behavior rule:
No public behavior changes are allowed.

Safety net:
- Run [tests] before change if possible.
- Run the same tests after each major step.

Allowed:
- [specific moves/extractions]

Not allowed:
- no feature changes,
- no validation behavior changes,
- no response schema changes,
- no opportunistic cleanup outside target area.

Output:
- Explain how behavior preservation is verified.

Add tests that increase behavioral confidence, not just coverage.

Behavior to prove:
- [behavior 1]
- [behavior 2]

Test oracle:
Given [setup]
When [action]
Then [observable result]

Rules:
- Follow existing test style in [test class].
- Avoid testing private implementation details unless existing module convention does so.
- Assertions must fail for meaningful behavior regressions.
- Do not add brittle timing sleeps.

Output:
- Tests added.
- What regression each test would catch.

Review this diff as a skeptical senior engineer.

Assess:
- correctness,
- edge cases,
- security/privacy,
- authorization,
- backward compatibility,
- test quality,
- maintainability,
- unnecessary complexity,
- performance risk,
- rollout risk.

Classify findings:
- Blocking: must fix before merge.
- Non-blocking: improvement suggestion.
- Question: needs clarification.

Do not nitpick style unless it affects maintainability or consistency.

Investigate the CI failure.

Inputs:
- Failing job: [name]
- Failing command: [command]
- Log excerpt: [log]
- Recent changes: [summary]

Workflow:
1. Identify the first meaningful failure, not cascading failures.
2. Map failure to changed files if possible.
3. Propose root cause hypotheses.
4. Make the smallest fix if root cause is clear.
5. Do not change unrelated code.
6. Do not disable checks.

Output:
- Root cause.
- Fix.
- Verification.
- Residual risk.

Update documentation to match the implementation.

Rules:
- Do not describe intended behavior that is not implemented.
- Prefer concise operational docs over marketing language.
- Include examples only if they are valid against current API/schema.
- Mention limitations and unsupported cases.

Output:
- Docs changed.
- Source of truth used.
- Any behavior that remains undocumented.

Search should support escalation reason.

Acceptance criteria:
1. Given no escalationReason parameter, search returns the same results as before.
2. Given escalationReason=MISSED_DEADLINE, search returns only cases with that reason.
3. Given escalationReason=UNKNOWN, API returns 400 with existing validation error shape.
4. Given user has access to J1 only, escalationReason filter cannot expose J2 cases.
5. Existing status/date filters compose with escalationReason using AND semantics.

Before finalizing, verify the diff against these invariants:
- [invariant 1]
- [invariant 2]
- [invariant 3]

For each invariant, state:
- preserved? yes/no
- where in code,
- where in tests,
- remaining risk.

Optimize for a small, reviewable diff.

Rules:
- Prefer editing existing functions over introducing new abstractions.
- Do not rename files or symbols unless required.
- Do not reformat unrelated code.
- Do not update dependencies.
- Do not perform opportunistic cleanup.
- If you notice cleanup opportunities, list them as follow-up instead.

Before implementation, list:
- Facts confirmed from code.
- Assumptions not yet confirmed.
- Questions that would change the implementation.

Proceed only if assumptions are low-risk and state them in the final summary.

Facts:
- Status filter uses CaseSearchPredicateBuilder.
- Validation errors use ProblemDetail.

Assumptions:
- Escalation reason is stored on current escalation record, not only in history.

Risk:
- If escalation reason should be historical, query logic must change.

Do not edit yet. First inspect the existing implementation path and tests. Return a plan with files to change.

Run or inspect the failing test before changing code. If you cannot run it, explain what evidence you used instead.

Do not run destructive commands such as deleting files, resetting branches, force pushing, dropping databases, or modifying migrations unless explicitly approved.

Ask before:
- adding dependencies,
- changing public contracts,
- introducing migrations,
- modifying authorization behavior,
- deleting tests,
- changing CI configuration.

Follow the pattern in CaseSearchStatusFilterTest for:
- enum parsing,
- invalid value assertions,
- no-filter behavior,
- ProblemDetail error shape.

Do not copy unrelated setup from older tests if newer tests use CaseSearchTestFixtures.

Use this old test as an example.

Before implementation, compare options:

Option A: extend existing predicate builder.
Option B: introduce generic enum filter abstraction.
Option C: add repository method for escalation reason.

Evaluate:
- consistency with current code,
- diff size,
- testability,
- performance,
- future extensibility,
- risk.

Recommend one. Bias toward minimal change unless future reuse is clearly justified.

Before coding, identify likely failure modes:
- invalid input,
- missing data,
- authorization interaction,
- concurrent execution,
- stale cache,
- transaction rollback,
- partial migration,
- external dependency failure.

For each, say whether this task must handle it now or leave it as out of scope.

Security review this change.

Check specifically:
- user-controlled input validation,
- authorization bypass,
- IDOR risk,
- PII exposure in logs/errors/events,
- injection risk in query construction,
- unsafe deserialization,
- dependency changes,
- secrets handling,
- insecure test-only shortcut leaking into production code.

Return blocking findings only unless there are important non-blocking risks.

Review performance risk.

Context:
- enforcement_case has about 80M rows.
- Search API p95 target is 300ms for common filters.
- escalationReason cardinality is low.
- Query must compose with jurisdiction filter.

Check:
- whether the predicate can use existing indexes,
- whether it causes table scan,
- whether join cardinality can explode,
- whether pagination remains stable,
- whether a new index or migration is needed.

Do not add an index unless you first explain migration risk.

Design the database migration plan.

Constraints:
- Zero downtime deployment.
- Applied migrations are immutable.
- Table has 80M rows.
- Backfill must be resumable.
- Application version N and N+1 may run concurrently during deployment.

Output:
- Expand step.
- Backfill step.
- Contract step.
- Rollback strategy.
- Verification queries.
- Risks.

Do not write migration SQL until the plan is approved.

Evaluate this design under distributed execution.

Assume:
- multiple app instances,
- retries from message broker,
- at-least-once delivery,
- database transaction rollback possible,
- duplicate commands possible.

Check:
- idempotency key,
- transaction boundary,
- event publication timing,
- optimistic/pessimistic locking,
- ordering assumptions,
- duplicate side effects,
- recovery after partial failure.

Review this change for regulatory defensibility.

Check:
- actor identity recorded,
- decision reason preserved,
- audit trail append-only,
- evidence redaction respected,
- jurisdiction visibility enforced,
- SLA calculation unchanged,
- policy basis traceable,
- notification content allowed,
- manual override distinguishable from system action.

For each issue, classify:
- legal/audit risk,
- operational risk,
- technical risk.

Implement feature X end to end.

Step 1: Discover implementation path. Do not edit.
Step 2: Propose plan. Do not edit.
Step 3: Implement approved minimal plan.
Step 4: Verify tests.
Step 5: Self-review diff.
Step 6: Prepare PR summary.

Find how status filters are implemented in case search. Do not edit. Return relevant files, tests, and current pattern.

Based on the discovered pattern, plan escalationReason filter implementation. Keep it under 5 steps. Do not edit.

Implement the plan. Keep the diff limited to request parsing, predicate builder, and tests. Run relevant tests.

Review the diff against scope, invariants, and test quality. Identify blocking issues only.

Planner: You may inspect files and propose a plan, but do not edit.
Implementer: Implement only the approved plan. Do not expand scope.
Tester: Add or improve tests for stated behavior. Do not change product code unless asked.
Reviewer: Review the diff skeptically. Do not modify files.

## Prompt Quality Rubric

Score 0-2 for each:

1. Intent clarity
2. Expected behavior clarity
3. Scope boundaries
4. Negative scope
5. Invariants
6. Relevant examples
7. Verification commands
8. Output format
9. Stop conditions
10. Task size

Interpretation:
- 0-7: unsafe prompt; rewrite.
- 8-14: usable for low-risk tasks.
- 15-20: suitable for production implementation.

Task:
[one-sentence task]

Intent:
[why]

Expected behavior:
- ...

Scope:
Allowed:
- ...
Not allowed:
- ...

Invariants:
- ...

Existing pattern:
Follow ...

Workflow:
1. Inspect relevant files.
2. Propose brief plan.
3. Implement smallest diff.
4. Add/update tests.
5. Run verification if possible.

Verification:
- ...

Output:
- plan,
- changed files,
- tests,
- verification,
- risks.

Do not edit files.

Investigate [topic] in this repository.

Find:
- current implementation path,
- relevant tests,
- relevant commands,
- constraints or invariants,
- likely files to change.

Return:
- concise findings,
- plan candidate,
- open questions,
- risk assessment.

Fix this bug conservatively.

Symptom:
...

Reproduction:
...

Expected behavior:
...

Rules:
- Change product code, not test expectations, unless the test is demonstrably wrong.
- Do not skip/disable tests.
- Keep fix close to root cause.
- Add regression test if missing.

Output:
- root cause,
- fix summary,
- tests,
- verification,
- residual risk.

Review the current diff as a skeptical senior engineer.

Focus only on issues that affect:
- correctness,
- security/privacy,
- authorization,
- compatibility,
- test confidence,
- performance,
- maintainability.

Classify findings:
- Blocking
- Non-blocking
- Question

Avoid style nitpicks unless they indicate inconsistency with existing project conventions.

Are you confident this works?

What evidence supports that this works?
List:
- tests run,
- tests added,
- behavior covered,
- invariants checked,
- assumptions not verified,
- remaining risks.

- [ ] Task satu intent.
- [ ] Expected behavior testable.
- [ ] Scope allowed dan not allowed jelas.
- [ ] Invariants ditulis.
- [ ] Existing pattern disebut.
- [ ] Verification command ada.
- [ ] Output format ada.
- [ ] Stop conditions ada untuk high-risk cases.
- [ ] Prompt tidak meminta refactor dan feature sekaligus.
- [ ] Prompt meminta evidence, bukan confidence.

- [ ] AI mengikuti workflow.
- [ ] AI tidak menyentuh file di luar scope.
- [ ] AI menyatakan asumsi.
- [ ] Tests benar-benar membuktikan behavior.
- [ ] Tidak ada weakened tests.
- [ ] Tidak ada security/authorization shortcut.
- [ ] Verification result jelas.
- [ ] Risk residual dicatat.