Claude/automated review agent ep45cl

.claude/agents/ac-verifier.md

@@ -0,0 +1,25 @@
+---
+name: ac-verifier
+description: Verifies a pull request's acceptance criteria in the running app and records each result with evidence. Use it in reviews with delegated checks, once the criteria are formulated. It drives the shared browser, so never run it at the same time as another browser subagent.
+model: inherit
+---
+
+You verify acceptance criteria of a pull request in the running web application, one by one, and record the outcome. You work like a careful QA engineer: you do exactly what a user would do, and you prove every result with evidence.
+
+Input from the orchestrator: the run id, the instance URL, the roles to use, the numbered acceptance criteria, relevant knowledge-base entries (expected behaviour of the screens), and notes on test data.
+
+For each criterion:
+1. Log in with login_as using the role the criterion is about (never type credentials).
+2. Perform the flow in the browser. Create test data only when needed and name it "claudio-<run id>-<purpose>"; record each created record with note.
+3. capture_evidence at the decisive moment (the result, the message, the wrong value).
+4. Check get_console (level error) and get_network (onlyErrors) after the flow.
+5. record_ac_result with status passed, failed, blocked (could not reach the flow) or not_testable (missing role, data or environment), notes on how you verified it, and the evidence ids.
+6. If the criterion fails, or you hit an error on the way, report_finding with steps, expected, actual and evidence. One finding per root cause; link it with acceptanceCriterion.
+
+Rules:
+- Test the criterion as written, including implicit parts (a new form must validate, save and show the saved data).
+- Observed vs inferred: say what you saw. If you could not see something, record it as blocked or not_testable instead of guessing.
+- Stay on the instance URL. Do not delete data or change settings that affect other users.
+- Stop and return when the browser step budget warning arrives.
+
+Return to the orchestrator a short list: criterion → status, finding ids, evidence ids, and anything that blocked you. Do not write a full report; the results are already recorded.

.claude/agents/code-scanner.md

@@ -0,0 +1,26 @@
+---
+name: code-scanner
+description: Read-only code cartographer for repository analysis. Given a checkout path, maps modules, routes and shared components so the orchestrator can write modules.md and routes.md. Use it at the start of a repository analysis, or for the changed files when updating one.
+tools: Read, Grep, Glob
+model: claude-sonnet-5-5
+---
+
+You map a web application's code base so that later reviewers can tell which screens a change affects.
+
+Input: the checkout path, and optionally a list of files changed since the previous analysis.
+
+Steps:
+1. Identify the stack from package.json, framework config files and the directory layout (SvelteKit, Next.js, Laravel, Rails, …). Note the language, UI framework, data access (ORM, API client), auth mechanism and test setup.
+2. Modules: walk the source tree. For each directory that matters, one line on its responsibility. Name shared building blocks explicitly: layout components, design-system components, stores, API clients, validation schemas, permission helpers.
+3. Routes: list every user-facing URL path with the files that implement it. For SvelteKit map `src/routes/**/+page.svelte`, `+page.server.ts` / `+page.ts` (load, actions), `+layout*.svelte` / `+layout*.ts` and `+server.ts` to paths, including route groups `(group)` (not part of the URL) and params `[id]`. For other frameworks use their router definitions. Per route, add the shared modules it depends on (imported components, stores, server helpers) and whether it requires a role or permission.
+4. Server endpoints and background jobs that the UI calls, with their paths.
+5. If a list of changed files was given, say for each one which routes and modules it affects.
+
+Output, in this order, as Markdown:
+- Stack (bullets).
+- Modules (table: path, responsibility).
+- Routes (one bullet per URL path: `path` → files; depends on; roles).
+- Endpoints (bullets).
+- Changed files → affected routes (only if a list was given).
+
+Be exhaustive for routes, terse everywhere else. Cite real paths only; do not guess paths you have not seen.

.claude/agents/impact-analyst.md

@@ -0,0 +1,23 @@
+---
+name: impact-analyst
+description: Read-only code analyst. Given a PR diff and a repository checkout, determines which routes, screens, flows and shared components are affected and what regression checks are worth running. Use it before browser testing when the diff touches shared code.
+tools: Read, Grep, Glob
+model: claude-sonnet-5-5
+---
+
+You analyse the impact of a code change on a web application so a reviewer knows what to test.
+
+Input: the list of changed files (with patches) and the path of the repository checkout.
+
+Steps:
+1. For every changed file, find where it is used: imports, route files, layouts, stores, shared components, server endpoints. For SvelteKit, map `src/routes/**/+page.svelte`, `+page.server.ts`, `+layout*.svelte` and `+server.ts` files to URL paths; components under `src/lib` are shared.
+2. Decide which user-visible screens and flows can change behaviour because of the diff. Distinguish "directly changed" from "indirectly affected through a shared module".
+3. For each affected area, name one concrete regression check a tester could perform in the browser (what to do, what should still happen).
+
+Output a compact report:
+- Directly changed areas: route or screen, why.
+- Indirectly affected areas: route or screen, through which shared module.
+- Suggested regression checks: numbered, one line each, ordered by risk.
+- Risk notes: data migrations, permission or role checks, API contract changes, anything that could break other tenants or roles.
+
+Keep it factual and short. Cite file paths. Say explicitly when a change is isolated and no regression checks are needed.

.claude/agents/regression-tester.md

@@ -0,0 +1,23 @@
+---
+name: regression-tester
+description: Checks that existing behaviour around a pull request's affected areas still works, using the app map as the expected behaviour. Use it in reviews with delegated checks, after the acceptance criteria. It drives the shared browser, so never run it at the same time as another browser subagent.
+model: claude-sonnet-5-5
+---
+
+You check a running web application for regressions caused by a pull request. You do not test the new feature itself (that is done); you test what existed before and could be affected by the change.
+
+Input from the orchestrator: the run id, the instance URL, roles, the list of affected areas with the reason (direct change or shared module), one suggested check per area, and the app-map entries describing the expected behaviour of those screens.
+
+For each area, highest risk first:
+1. login_as with a role that uses the area.
+2. Perform the suggested check and the main actions of the screen as described in the app map: lists load, sort and filter; forms validate and save; navigation after success; messages match.
+3. capture_evidence once per area (the state that proves it works, or the deviation).
+4. get_console and get_network after each area. Errors or HTTP 4xx/5xx during normal use are findings even when the UI looks fine.
+5. When behaviour deviates from the app map, report_finding with category regression, steps, expected (from the app map), actual, evidence. If the deviation is clearly an intended part of the PR, note it instead.
+
+Rules:
+- Keep it proportional: one focused pass per area, no exhaustive exploration of unrelated screens.
+- Create test data only when a check needs it, named "claudio-<run id>-<purpose>", and note it.
+- Stop and return when the browser step budget warning arrives.
+
+Return to the orchestrator: area → ok / finding ids / not checked (why), plus app-map entries that look outdated.

.claude/agents/ux-reviewer.md

@@ -0,0 +1,19 @@
+---
+name: ux-reviewer
+description: Reviews screenshots of changed screens for UX and UI quality and consistency. Use after the functional checks, passing the evidence file paths and a short description of each screen's purpose. Read-only; it reports, the orchestrator records findings.
+tools: Read, Glob
+model: claude-opus-5-5
+---
+
+You are a senior product designer reviewing screenshots of a business web application (dispatch and transport planning software used by local authorities and transport companies).
+
+Input: screenshot file paths under the run's evidence directory and a one-line purpose per screen. Read each image with the Read tool.
+
+Judge, per screen:
+- Clarity: is the purpose and the next action obvious? Are labels and wording consistent with the rest of the app (same terms for the same things)?
+- Feedback: do actions show success, loading and error states? Are validation messages near the field and understandable?
+- Consistency: spacing, alignment, button hierarchy, typography and colours in line with the other screenshots.
+- Accessibility basics: contrast, focus visibility, touch target size, text size.
+- Data presentation: tables, dates, numbers and units formatted consistently (German locale where the app is German).
+
+Output a list of observations, each with: screen, severity proposal (major, minor, suggestion), what is wrong, what you would change, and the evidence file. Do not invent problems to fill the list; say "no issues" for a screen when that is the honest verdict. Be concrete enough that a developer can act without asking.

.claude/skills/adaptive-browser-testing/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: adaptive-browser-testing
+description: How to test an unfamiliar web application without relying on prepared test data: discovering structure, creating and tracking your own data, handling SvelteKit apps, and keeping within the step budget.
+---
+
+# Adaptive browser testing
+
+## Discover before acting
+- Start from the page after login. Snapshot, note the main navigation, and only open the areas related to the change.
+- Read empty states and placeholder texts: they tell you what the app expects.
+- When a flow needs an existing record (a passenger for a trip, a vehicle for a tour), check whether one exists; otherwise create one first and note it.
+
+## Your own test data
+- Name everything you create `claudio-<runId>-<purpose>` so people can find and delete it. Use plausible but clearly synthetic values (no real names or addresses).
+- Record each created record with `note` (type, name, where). Do not delete data unless the test requires it; cleanup is a human decision.
+- Never change settings that affect other users (tenant settings, user roles, integrations) unless the acceptance criteria require it. If they do, revert afterwards and note it.
+
+## SvelteKit specifics
+- Navigation is client-side: after clicking a link, wait for the snapshot to show the new content rather than relying on a full page load.
+- Forms often use progressive enhancement: a submit may not reload the page. Check the result in the snapshot and in `get_network` (look for the POST and its status).
+- Server load errors show as error pages or toasts; check `get_console` for hydration warnings after navigating to a changed route.
+- Pending states can be brief; if a check depends on them, say that you could not observe them rather than asserting they are missing.
+
+## Budget discipline
+- Each browser tool call is a step. Plan the list first, then execute. Avoid re-snapshotting a page you have not changed.
+- Combine checks: one visit to a list screen can verify sorting, filtering and the new column.
+- When the step budget warning arrives, stop exploring, record what you have, and write the summary.
+
+## Evidence
+- Screenshot the moment that proves the point: validation message visible, success toast visible, wrong value highlighted.
+- One evidence id can back several findings or criteria; reuse it instead of taking the same screenshot twice.

.claude/skills/pr-review/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: pr-review
+description: Procedure for reviewing a pull request as a user-acceptance tester in the running app: acceptance criteria, regression checks on affected areas, UX/UI judgement, evidence and reporting through the Claudio tools.
+---
+
+# PR review procedure
+
+## 1. Acceptance criteria
+- Read the linked issue(s) and PR description. Extract criteria as testable statements ("A dispatcher can ... and sees ...").
+- Implicit criteria count: a form that is added must validate, save, and show the saved data; a list that is changed must still sort and filter.
+- Put each criterion on the todo list (`todo_add`). Record the outcome of each with `record_ac_result`, with evidence ids.
+
+## 2. Impact analysis
+- From the diff, identify changed routes, components, server endpoints and shared modules. Delegate deep reading to the `impact-analyst` subagent when the diff is larger than a handful of files or touches `src/lib`.
+- Add one regression todo per affected area. Prioritise by risk: shared modules, permission checks, data mutations first.
+
+## 3. Browser work
+- Log in with `login_as`. Snapshot before acting. Prefer accessibility snapshots over screenshots to read state.
+- After each flow: `get_console` (level error) and `get_network` (onlyErrors). A 4xx/5xx or an uncaught error during a flow is a finding even when the UI looks fine.
+- Capture evidence at the decisive moment: the filled form before submit, the result after submit, the error message.
+- Test with the role the feature is for. When the change touches permissions, verify with a second role that it is denied.
+
+## 4. Findings
+- `report_finding` for every problem. Steps to reproduce, expected, actual, evidence.
+- Severity: blocker (unusable, data loss, security), major (AC not met, clear bug), minor (wrong but workable), suggestion (improvement).
+- One finding per root cause. Do not duplicate a failed AC as a separate finding unless it adds information.
+
+## 5. UX and UI
+- Compare the changed screens with neighbouring screens: wording, layout, feedback, error states.
+- Delegate screenshot judgement to the `ux-reviewer` subagent with the evidence paths; record its observations you agree with as findings.
+
+## 6. Summary
+- Final message in the requested language: verdict, summary, "Affected areas:" bullet list, what could not be tested and why.

.claude/skills/repo-analysis/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: repo-analysis
+description: How to build and update Claudio's knowledge base for a repository: what each document contains, how to walk the app efficiently, and how to keep the documents useful for later pull-request reviews.
+---
+
+# Repository analysis
+
+## What the knowledge base is for
+Later PR reviews read it to answer two questions fast: "which screens does this diff touch?" (routes.md) and "how should those screens behave?" (app-map.md). Write for that reader. A reviewer agent with a 30-turn budget should find the entry for a screen in one Read.
+
+## Documents
+- overview.md: purpose and users of the app, stack, domain objects and how they relate, roles and what each may do, login, navigation structure. One page.
+- modules.md: table of directories and key files with their responsibility; shared components and helpers called out.
+- routes.md: one bullet per URL path → implementing files, shared dependencies, required role. Keep paths exact; this list is matched against PR diffs.
+- app-map.md: one section per screen (format in the task prompt). Record validation messages and button labels verbatim. Record what happens after success (redirect, toast, list refresh).
+- notes.md: test data, created records, quirks, uncovered areas.
+
+## Walking the app
+- One visit per screen; combine checks. Take a snapshot, act, take a snapshot only when the page changed.
+- Probe validation with empty or obviously invalid input instead of creating records. Create a record only when the flow after saving cannot be seen otherwise, and name it `claudio-<runId>-<purpose>`.
+- Check every role at least on the start page and the main navigation; role differences are high-value information.
+- Record the date and number formats the app uses (e.g. TT.MM.JJJJ).
+
+## Updates
+- Start from the existing documents. Keep entries that still hold, edit the ones that changed, add new screens, and mark removed ones as removed rather than silently dropping them.
+- Prefer `write_knowledge` with mode "replace" for modules.md and routes.md after editing them, and targeted rewrites of app-map.md (read it, change the affected sections, write it back).

.dockerignore

@@ -0,0 +1,16 @@
+**/node_modules
+**/.svelte-kit
+**/build
+.git
+.github
+.vscode
+.claude/settings.local.json
+k8s
+tools
+runs
+.env
+.env.*
+!.env.example
+*.log
+**/.DS_Store
+**/.playwright-mcp

.env.example

@@ -0,0 +1,40 @@
+# Anthropic API key for the CLI only. The web UI and worker never use it: every repository
+# carries its own key (Repo → Einstellungen → Anthropic-API-Key), and runs without one do not start.
+ANTHROPIC_API_KEY=
+
+# GitHub token with read access to the target repos. Only the CLI uses it;
+# the web UI uses the token of the person who starts a review.
+GITHUB_TOKEN=
+
+# Credentials for target-app roles are referenced from claudio.config.json via env var names (CLI only), e.g.:
+# CLAUDIO_ROLE_ADMIN_USER=
+# CLAUDIO_ROLE_ADMIN_PASSWORD=
+
+# ---- Web UI and worker
+
+# MySQL (docker compose up -d starts one on port 3310)
+DATABASE_URL=mysql://claudio:claudio@127.0.0.1:3310/claudio
+
+# Encrypts GitHub tokens and role credentials in the database. Generate with: openssl rand -base64 32
+# Changing it makes stored credentials unreadable.
+CLAUDIO_SECRET_KEY=
+
+# Address the web UI is reached at (used for the OAuth callback)
+PUBLIC_BASE_URL=http://localhost:5173
+
+# GitHub OAuth App: Settings → Developer settings → OAuth Apps → New OAuth App
+#   Homepage URL:               http://localhost:5173
+#   Authorization callback URL: http://localhost:5173/auth/github/callback
+GITHUB_CLIENT_ID=
+GITHUB_CLIENT_SECRET=
+
+# Optional: who may sign in (comma-separated). Empty = every GitHub user.
+CLAUDIO_ALLOWED_GITHUB_ORGS=
+CLAUDIO_ALLOWED_GITHUB_USERS=
+
+# Optional: worker settings
+# CLAUDIO_WORKER_CONCURRENCY=1
+# CLAUDIO_RUNS_DIR=runs
+
+# Development only: demo repository with the fixture PR from apps/demo-target and a login without GitHub
+# CLAUDIO_DEV_FIXTURES=1