Cline · Scala · Play Framework · Popular baseline

# Cline · Scala + Play Framework  
Generated February 10, 2026  
Agent: Cline  
Language: Scala  
Framework: Play Framework

## Global rules
- Start by reading existing project instructions and architecture docs before changing behavior.

- Prefer minimal diffs and preserve existing code style and naming conventions.

- State assumptions and call out risks before making breaking or cross-module changes.

- When behavior changes, add or update tests in the closest existing test layer.

- Never commit secrets, tokens, credentials, or generated private keys.

Start by reading existing project instructions and architecture docs before changing behavior.

Prefer minimal diffs and preserve existing code style and naming conventions.

State assumptions and call out risks before making breaking or cross-module changes.

When behavior changes, add or update tests in the closest existing test layer.

Never commit secrets, tokens, credentials, or generated private keys.

## Agent-specific
- Be explicit with shell commands and expected outcomes.

- Perform targeted validation after each meaningful patch.

- Keep edits tightly scoped to the requested objective.

## Language-specific
- Prefer immutable data and total functions for domain logic.

- Model failures explicitly with Either/Try instead of throwing across boundaries.

- Keep effectful code at edges and business logic pure where possible.

## Framework-specific
- Use typed routes and explicit request parsing/validation.

- Keep controllers thin and domain logic in services/use-cases.

## Options

### Testing rules
- Require tests for changed behavior or document why tests were not added.

- Run the smallest relevant test subset first, then broaden if needed.

### Architecture rules
- Preserve module boundaries and avoid leaking internal abstractions.

- Prefer incremental refactors over large rewrites.

### Security rules
- Validate and sanitize all user-controlled input.

- Apply least-privilege defaults for data access and actions.

### Ask before changing public API
- Before changing a public API, present the impact and ask for explicit confirmation.

- If approved, document the migration path for consumers.

### Prefer minimal diffs
- Limit changes to the smallest set of files and lines needed.

- Defer unrelated cleanup to separate follow-up changes.

### Documentation rules
- Update docs/examples whenever behavior, APIs, or setup steps change.

- Add concise release notes for user-facing or breaking changes.