Help me configure Jina for this repository. Jina is an autonomous AI QA engineer that performs runtime investigations on pull requests.

Do not edit files yet. First inspect the repository deeply enough to tailor the policy:

- Read the README, contributor or agent instructions, architecture docs, package manifests, CI configuration, test setup, deployment configuration, and operational documentation.
- Identify the runtime architecture, service boundaries, persistence and queue layers, external contracts, authentication model, critical product flows, and existing test commands.
- Inspect git status and preserve all existing work.
- If `.jina` exists, read each of the six supported files that is present and identify duplication or contradictions.
- Do not ask me for facts you can learn from the repository. Summarize what you learned before asking questions.

Use only this supported configuration contract:

- `.jina/config.json` supports one key: integer `depth` from 1 through 5. It is the maximum number of investigation rounds; the default is 2 and Jina may stop early.
- `.jina/instruction.md` contains global priorities, scope and skip rules, evidence requirements, safety rules, and writing preferences. Put policy here by default so it reaches every stage.
- `.jina/planner/instruction.md` controls first-round scope, risk-area selection, and when repository policy may skip substantive standard investigation.
- `.jina/replanner/instruction.md` controls evidence-driven follow-up and deepening between rounds.
- `.jina/investigation/instruction.md` contains executable checks, fixtures, safe environment rules, forbidden operations, and proof standards.
- `.jina/review/instruction.md` contains severity, merge-score, validation, and presentation policy.
- Use only the config key and filenames listed above.
- Keep issue severities exactly P0, P1, P2, or P3 and merge scores as integers from 1 to 5.
- Protected evidence, truthfulness, output-schema, base-branch trust, and sandbox-safety requirements cannot be overridden.
- Bias toward `.jina/instruction.md`. Do not split policy across stage files unless a rule is genuinely relevant to only one stage.

After your repository summary, interview me in short, contextual batches. Ask only questions that materially affect the setup. Cover:

1. The product flows and invariants we cannot afford to break.
2. The highest-cost production failures for this system, including relevant authorization, tenant isolation, data integrity, idempotency, retry, compatibility, performance, deployment, or external-integration risks.
3. Which files, paths, generated artifacts, issue types, and low-value concerns to de-prioritize; when the entire standard review may be skipped; and which exceptions must always trigger a run.
4. The evidence required before Jina reports an issue: commands, tests, API calls, fixtures, logs, or reproductions.
5. Safe local services and credentials, plus commands, environments, endpoints, or data Jina must never use.
6. Our P0-P3 severity definitions, 1-5 merge-score rubric, false-positive tolerance, and preferred summary style. Preserve the fixed severity and score values.
7. The repository baseline depth from 1 to 5. Explain the likely review-time and model-usage tradeoff before asking me to choose.
8. Whether review action or depth should adapt by change type. For each change class, collect the standard action (`run` or `skip`), desired depth, and exceptions. Plan to return numeric adaptive-depth rules as a separate workspace review-preference snippet because `.jina/config.json` only sets the repository baseline.

When the interview is complete:

1. Recommend the smallest useful `.jina` tree. Put reusable policy in the global instruction. Add `config.json` only when we want an explicit versioned baseline, and add a stage file only when it contains genuinely stage-specific policy.
2. Present the complete proposed tree and full contents of every proposed file.
3. Include a concise policy matrix: change class, standard action, depth, exceptions, and where the rule is configured.
4. Explain why each file exists, what it changes, and any policy you deliberately left out.
5. Check for vague exclusions, over-broad skips, duplicated rules, contradictory scoring, unsafe commands, secrets, invalid JSON, and instructions that attempt to override protected Jina behavior.
6. If adaptive numeric-depth rules are needed, include a separate workspace review-preference snippet and explain that an authorized workspace admin must save it in Jina settings.
7. Stop and wait for my explicit confirmation.

Only after I confirm:

- Create or update the approved `.jina` files and no unrelated source files.
- Preserve useful existing guidance and existing uncommitted work.
- Validate `config.json`, exact filenames, file sizes, internal consistency, and `git diff --check`.
- Show the final diff summary and explain the effective baseline depth, stage policies, exclusions, evidence standard, scoring rubric, and workspace preference.
- Remind me that Jina reads repository policy from the base commit, so this policy begins governing reviews only after it is merged and used as the base of a later pull request.

# Review policy

## Prioritize

- Cross-tenant authorization failures.
- Data loss, duplicate effects, and unsafe retries.
- Backward-incompatible API or event changes.

## De-prioritize

- Style, naming, and formatting without a behavior failure.
- Generated files unless the change can alter production behavior.

## Evidence

- Identify the triggering state, input, and affected path.
- Prefer a repeatable command, test, API call, or probe.
- Do not report speculative or pre-existing issues.

.jina/
├── config.json
├── instruction.md
├── planner/
│   └── instruction.md
├── replanner/
│   └── instruction.md
├── investigation/
│   └── instruction.md
└── review/
    └── instruction.md

{
  "depth": 3
}

## Review action

- Run when a change can affect runtime code, authorization, data, APIs, jobs, deployment, or infrastructure.
- Skip substantive standard investigation only when the change cannot alter runtime behavior, deployment behavior, or an external contract.
- Do not skip from a directory name alone. Check whether the changed file affects a direct dependency or generated runtime artifact.

# Planning criteria

- Trace changed handlers into authorization, persistence, queues, and external contracts.
- Prioritize checkout, billing, and account-recovery flows when they are in the blast radius.
- Include direct dependencies needed to prove a changed behavior.
- Do not spend an area on docs, fixtures, or generated clients unless they can change runtime behavior.
- Skip substantive investigation only when the change has no production execution path.

# Follow-up criteria

- Add a round only when earlier evidence exposes a new dependency or plausible root cause.
- Deepen an area when one focused probe can turn an inconclusive result into proof.
- Carry forward the exact command, output, and state needed by the next investigator.
- Do not broaden into unrelated code or repeat a path that was already validated.

# Investigation policy

## Preferred checks

- Run the narrowest existing test before writing a new probe.
- Use documented local fixtures for database and queue state.
- Exercise changed API contracts with realistic request and identity data.

## Evidence standard

- Capture the exact command and observed output.
- Show the input or state that triggers the failure.
- Confirm that the pull request caused the behavior.

## Safety

- Use local or ephemeral services only.
- Never call production, shared staging, or destructive maintenance endpoints.
- Do not use real customer data or credentials.

# Review and scoring

- Use 5/5 when no confirmed production-impact issue remains.
- Use 4/5 for a confirmed concern that is safe to merge and follow up.
- Use 3/5 when a well-evidenced issue should be fixed before a normal release.
- Use 2/5 or 1/5 for validated failures that block important or core production behavior.
- Keep the summary focused on the merge decision, root cause, and user impact.
- Do not reduce the score for complexity or missing tests without a concrete failure.

Review docs-only and low-risk UI changes lightly. Go deep on authentication,
payments, tenant isolation, data migrations, and core infrastructure. Skip
substantive standard investigation for generated-file-only changes only when
their source and runtime consumers are unchanged. Run at the configured baseline
when no rule matches.

@usejina review depth 5 on the standard review and for scenarios go 2 layers deep