feat: triage agentic workflow (IMPL-0025) — WIP

[galanko]

User description

Status: draft / in progress. Implementing the triage agentic workflow per the approved design.

What this is

Two-speed triage: keep the $0 Quick read (ADR-0051 synthesizer) as the default, add a read-only, plan-don't-execute agentic Deep dive that escalates only on uncertainty/stakes within a budget, grounded by a new per-repo Project profile (repo knowledge base). Validated by an eval whose dataset stays private in cliff-os (ADR-0050 hybrid).

Design of record (private cliff-os): PRD-0008 rev. 2 + PRD-0009; ADR-0052 + ADR-0053; IMPL-0025.

Phase 1 — Repo knowledge base (ADR-0053) ✅

repo entity + canonicalizer + migration; atomic store + lazy PROFILE.md; one-build CAS mutex + reaper; credential-less clone + GC; access layer; 3 read-only profile builders; eager profiling at scan; /api/repos/profile* + dashboard card.

Phase 2 — the Deep dive (ADR-0052) ✅

deep-dive schemas (additive TriageOutput, no migration); read-only grep; model tiering (amends ADR-0037); escalation gate + budget (severity alone never escalates); the five agents gather_facts → rule_out → trace_path → plan_exploit → challenge (deterministic majority-refutes resolution); DeepDiveRunner with fail-cheap exits, wired into the triage path (best-effort, never breaks triage).

Phase 3 — the eval (ADR-0052 §Evaluation) ✅

Harness here (public); the valuable dataset lives in private cliff-os/eval and never enters this repo.

• deterministic HARD gates: false-clear (golden real never cleared, zero-tolerance), citation grounding (every cited file:line resolves — fabrication caught by code, no judge), read-only tool boundary; graded verdict-match
• run_deep_dive_eval (stages case.files → temp repo) + make_live_deep_dive_pipeline (real DeepDiveRunner for the private live lane)
• tiny synthetic CI sample in this repo; the moat dataset (vulnerable/patched pairs, the research-vertical corpus) is private
• 8 tests proving the gates fire

Remaining

• Phase 4 — UI (exploit-plan card + challenge trail + narration; needs UX-0009)
• Phase 5 — LSP fast-follow
• Phase 6 — sandbox / live execution — separate future ADR, NOT in this PR

All TDD-first, TestModel in CI (no real LLM). Do not merge — for review by @galanko.

🤖 Generated with Claude Code

---

Generated description

Below is a concise technical summary of the changes proposed in this PR:
Drive the ADR-0052 agentic Deep dive by wiring DeepDiveRunner, the stage agents/challenge panel, retry/budgeted read+grep tools, and the deterministic eval into triage so uncertain/high-stakes findings safely escalate. Bootstrap ADR-0053’s repo knowledge base via RepoDirManager/ProfileRunner plus the repo APIs and dashboard card so every Deep dive run is grounded in a canonical project profile that users can inspect or refresh.

Topic	Details
Repo knowledge base	Stand up the ADR-0053 repo knowledge base: canonical repo entity/migration, DAO + profile store, credentialless clone + GC adapters, RepoDirManager schema/knowledge surface, profile builders/runner/service, API, frontend hooks/tests, and dashboard wiring so triage reads resilient project context and users can trigger/observe profile builds. Modified files (32) backend/cliff/api/routes/repos.py backend/cliff/db/migrations/025_repo_entity.sql backend/cliff/main.py backend/cliff/models/__init__.py backend/cliff/models/repo.py backend/cliff/repos/__init__.py backend/cliff/repos/clone.py backend/cliff/repos/dao.py backend/cliff/repos/gc.py backend/cliff/repos/git_ops.py backend/cliff/repos/identity.py backend/cliff/repos/knowledge.py backend/cliff/repos/profile_agents.py backend/cliff/repos/profile_runner.py backend/cliff/repos/repo_dir_manager.py backend/cliff/repos/schemas.py backend/cliff/repos/service.py backend/tests/api/openapi_snapshot.json backend/tests/repos/__init__.py backend/tests/repos/conftest.py backend/tests/repos/test_clone.py backend/tests/repos/test_git_ops.py backend/tests/repos/test_identity.py backend/tests/repos/test_knowledge.py backend/tests/repos/test_profile_agents.py backend/tests/repos/test_profile_runner.py backend/tests/repos/test_repo_dao.py backend/tests/repos/test_repo_dir_manager.py backend/tests/repos/test_service.py backend/tests/test_routes_repos.py frontend/src/api/__tests__/repos.test.tsx frontend/src/api/repos.ts Latest Contributors(1) User Commit Date galank@gmail.com fix(triage): address C... June 14, 2026
Deep dive flow	Orchestrate the escalation-gated Deep dive flow: tier the models, cap read/grep output, define the stage prompts/challenge panel, assemble DeepDiveRunner/integration into triage, extend the schema/sidebar contracts, and ship the evaluation harness + UI coverage so every agent run stays deterministic, read-only, and safely degrades. Modified files (36) backend/cliff/agents/runtime/deps.py backend/cliff/agents/runtime/model_tiers.py backend/cliff/agents/runtime/tools/__init__.py backend/cliff/agents/runtime/tools/grep.py backend/cliff/agents/runtime/tools/read.py backend/cliff/agents/schemas.py backend/cliff/agents/triage_deep/__init__.py backend/cliff/agents/triage_deep/agents.py backend/cliff/agents/triage_deep/challenge.py backend/cliff/agents/triage_deep/escalation.py backend/cliff/agents/triage_deep/integration.py backend/cliff/agents/triage_deep/runner.py backend/cliff/agents/triage_runner.py backend/cliff/api/routes/agent_execution.py backend/cliff/api/routes/assessment.py backend/cliff/evals/__init__.py backend/cliff/evals/cases.py backend/cliff/evals/deep_dive_evaluators.py backend/cliff/evals/repo_fetch.py backend/cliff/evals/runners.py backend/tests/agents/eval/triage_deep_dive.jsonl backend/tests/agents/test_deep_dive_agents.py backend/tests/agents/test_deep_dive_integration.py backend/tests/agents/test_deep_dive_runner.py backend/tests/agents/test_deep_dive_schemas.py backend/tests/agents/test_escalation.py backend/tests/agents/test_evals_deep_dive.py backend/tests/agents/test_grep_tool.py backend/tests/agents/test_model_tiers.py backend/tests/agents/test_read_budget.py backend/tests/agents/test_repo_fetch.py frontend/src/api/client.ts frontend/src/components/dashboard/ProjectProfileCard.tsx frontend/src/components/issues/IssueSidePanel.tsx frontend/src/components/issues/__tests__/IssueSidePanel.test.tsx frontend/src/pages/DashboardPage.tsx Latest Contributors(1) User Commit Date galank@gmail.com fix(triage): address C... June 14, 2026

_{Review this PR on Baz | Customize your next review}

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR adds deep-dive scanner triage with staged agents and challenge review, introduces per-repo profile storage/build APIs and background jobs, extends evaluation support for live repo checkouts, and surfaces repo profiles plus deep-dive triage details in the frontend.

Changes

Deep dive triage and repo profiling

Layer / File(s)	Summary
Runtime contracts and tool limits backend/cliff/agents/runtime/deps.py, backend/cliff/agents/runtime/model_tiers.py, backend/cliff/agents/runtime/tools/*, backend/cliff/agents/schemas.py	Adds read budgeting, provider tier resolution, a read-only grep tool, and new deep-dive triage schema fields and stage artifact models.
Repo entity, storage, and profile build flow backend/cliff/repos/*, backend/cliff/models/repo.py, backend/cliff/models/__init__.py, backend/cliff/db/migrations/025_repo_entity.sql, backend/cliff/api/routes/repos.py, backend/cliff/api/routes/assessment.py, backend/cliff/main.py	Creates the repo table, URL canonicalization, clone/profile storage managers, profile build orchestration and scheduling, and API endpoints for profile status and rebuild.
Deep-dive triage execution and scanner wiring backend/cliff/agents/triage_deep/*, backend/cliff/agents/triage_runner.py, backend/cliff/api/routes/agent_execution.py	Implements staged deep-dive agents, escalation decisions, challenge/disproof panels, runner orchestration, repo knowledge loading, and best-effort scanner triage escalation.
Evaluation harness and backend validation backend/cliff/evals/*, backend/tests/agents/*, backend/tests/repos/*, backend/tests/test_routes_repos.py, backend/tests/api/openapi_snapshot.json	Adds deep-dive eval runners and gates, pinned-SHA repo checkout support, synthetic eval data, and backend tests covering deep-dive flow, repo profiling, runtime limits, and API contracts.
Frontend API and UI surfaces frontend/src/api/client.ts, frontend/src/api/repos.ts, frontend/src/api/__tests__/repos.test.tsx, frontend/src/components/dashboard/ProjectProfileCard.tsx, frontend/src/components/issues/IssueSidePanel.tsx, frontend/src/components/issues/__tests__/IssueSidePanel.test.tsx, frontend/src/pages/DashboardPage.tsx	Adds repo-profile client hooks and dashboard rendering, extends triage types for deep-dive fields, and renders exploit plan, challenge, and provenance details in the issue side panel.

Sequence Diagram(s)

sequenceDiagram
  participant Route as POST /findings/{id}/triage
  participant TriageRunner as run_triage
  participant DeepDive as maybe_deep_dive
  participant RepoStore as RepoDirManager
  participant Runner as DeepDiveRunner

  Route->>TriageRunner: run_triage(ai_env, model_full_id)
  TriageRunner->>TriageRunner: build quick triage
  TriageRunner->>DeepDive: maybe_deep_dive(quick, repo_url, finding)
  DeepDive->>RepoStore: load profile/code_map/threat + clone_dir
  DeepDive->>Runner: run(finding, repo_knowledge, clone_dir)
  Runner-->>TriageRunner: deep-dive TriageOutput
  TriageRunner-->>Route: selected triage result

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Possibly related PRs

• cliff-security/cliff#221: Extends the same runtime dependency container by adding read_budget to WorkspaceDeps.
• cliff-security/cliff#267: Updates the shared TriageOutput contract that this PR further extends with deep-dive fields.
• cliff-security/cliff#251: Builds on the runtime read tool by adding read-budget enforcement and the companion grep tool.

Suggested reviewers

• baz-reviewer

Poem

🐇 I sniffed through code in a moonlit dive,
Found profiles and triage all spring alive.
With grep in paw and budgets tight,
The burrow now maps each repo right.
I thump with joy: what a well-wired night!

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/triage-agentic-workflow

[baz-reviewer]

maybe_deep_dive() is called without budget_remaining, so DEFAULT_DEEP_DIVE_BUDGET resets per finding and the budget_remaining > 0 gate in decide_escalation() never really decrements — should we thread a persisted remaining budget through run_triage and pass it in?

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
backend/cliff/agents/triage_runner.py around lines 182-191 inside the
_run_scanner_triage method, update the call to maybe_deep_dive to pass an explicit
remaining budget (instead of relying on integration.py’s DEFAULT_DEEP_DIVE_BUDGET
fallback). Refactor run_triage (around lines 109-138) and _run_scanner_triage (around
lines 141-201) to accept/load a persisted remaining-budget value for this
finding/assessment from the DB, decrement it according to the deep-dive decision, and
persist the updated remaining budget so decide_escalation() can’t effectively reset to
10 per finding. Ensure the scanner path mirrors whatever budget handling already exists
on the report triage path so the per-assessment escalation cap in escalation.py is
respected.

Heads up!

Your free trial ends tomorrow.
To keep getting your PRs reviewed by Baz, update your team's subscription

[baz-reviewer]

_run_report_triage(...) still returns sidebar.triage after report_triager and skips maybe_deep_dive, so decide_escalation(..., source="report") stays unreachable for reports — should we route this path through maybe_deep_dive(..., source="report", ai_env/model args) like the non-report flow?

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
backend/cliff/agents/triage_runner.py around lines 204 (the _run_report_triage helper),
stop short-circuiting after report_triager/sidebar triage returns, and instead route the
report verdict through maybe_deep_dive just like _run_scanner_triage does. Update
_run_report_triage’s signature to accept ai_env and model_full_id, and update
run_triage (around the REPORT_SOURCE_TYPE branch) to pass those arguments into
_run_report_triage. When building the parameters for maybe_deep_dive, ensure the
deep-dive/escalation logic can detect this is the report path (e.g., pass
source="report" if supported, or include enough context like finding.source_type/source)
and keep the “best-effort: keep quick verdict on deep-dive failure” behavior
consistent.

Heads up!

Your free trial ends tomorrow.
To keep getting your PRs reviewed by Baz, update your team's subscription

[baz-reviewer]

Commit b27affb addressed this comment by routing _run_report_triage(...) through maybe_deep_dive(...) instead of returning sidebar.triage مباشرة. It now passes ai_env, model_full_id, and source="report", and preserves the best-effort fallback to the quick verdict on deep-dive failure.

[baz-reviewer]

The AI cache lookup here duplicates cliff.repos.service.schedule_profile_build, should we resolve it once via shared app.state.ai_env_resolver/ai_model_resolver helpers?

Want Baz to fix this for you? Activate Fixer

Heads up!

Your free trial ends tomorrow.
To keep getting your PRs reviewed by Baz, update your team's subscription

[baz-reviewer]

_kill_corroborated should check RuleOutResult.dedup_match against threat.prior_issues[*].id instead of treating any non-empty prior_issues as enough, otherwise unrelated history can clear a new finding.

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
backend/cliff/agents/triage_deep/runner.py around lines 91-107, in the
`_kill_corroborated` helper, the `duplicate_of_known` branch incorrectly returns true
whenever `repo_knowledge['threat']['prior_issues']` is non-empty, even if
`RuleOutResult.dedup_match` didn’t match that prior issue. Refactor this branch to
read the matched prior issue id from the `ro` dict (e.g., `ro.get('dedup_match')` or the
appropriate field name) and return true only when a prior issue in
`repo_knowledge['threat']['prior_issues']` has `id` equal to that matched id. Keep the
existing structural check for `root_cause_in_nonship_code`, but ensure the duplicate
gate requires an id-level corroboration rather than mere history presence.

Heads up!

Your free trial ends tomorrow.
To keep getting your PRs reviewed by Baz, update your team's subscription

[baz-reviewer]

Commit 46b0f2f addressed this comment by changing duplicate_of_known to require ro.get("dedup_match") to match one of the threat history prior_issues[*].id values. This removes the old behavior where any non-empty prior history could clear an unrelated new finding.

[baz-reviewer]

Deep-dive stages return result.output.model_dump() straight into TriageOutput, so agent_run/SidebarState never get the intermediate gather_facts/rule_out/trace_path/plan_exploit/challenge results; should we persist each stage or route them through the normal executor before finalizing?

Want Baz to fix this for you? Activate Fixer You can also update your AI coding guidelines based on this comment by apply pr to [branch name]

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
backend/cliff/agents/triage_deep/agents.py around lines 229-234 in the _run(agent, deps)
function, the code currently returns result.output.model_dump() without persisting the
stage output anywhere. Update _run (and thus
run_gather_facts/run_rule_out/run_trace_path/run_plan_exploit) to write each stage
result to both required sinks: create the chat-timeline agent_run entry and persist the
intermediate output to SidebarState before returning the final verdict. Prefer routing
stage execution through the project’s normal agent executor/persistence utility (the
one used by other agents) so logging and SidebarState updates happen consistently;
otherwise, add explicit persistence calls right after run_agent_with_retry returns and
before result.output.model_dump() is returned.

Heads up!

Your free trial ends tomorrow.
To keep getting your PRs reviewed by Baz, update your team's subscription

[coderabbitai]

Actionable comments posted: 17

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@backend/cliff/agents/runtime/deps.py`:
- Around line 27-33: The take() method in the ReadBudget class only checks if
the budget is already exhausted before subtracting, but does not validate
whether the requested amount n can actually be deducted without going negative.
This allows an oversized read to bypass the limit on the first occurrence. Fix
this by changing the condition to check if the remaining budget is sufficient
before allowing the deduction — replace the condition that checks if remaining
<= 0 with a check that verifies self.remaining < n, ensuring that take() returns
False whenever the requested deduction would violate the budget cap.

In `@backend/cliff/agents/runtime/model_tiers.py`:
- Around line 54-65: The clearing_is_trusted function accepts malformed model
IDs as trusted by checking only the provider name portion. Malformed inputs like
"openai" (missing the "/" separator) will incorrectly be treated as trusted even
though they are not valid provider/model configurations. Modify the return
statement to validate that model_full_id actually contains a "/" separator
before checking if the provider portion is in _LINEUP, ensuring that only
properly formatted provider/model IDs with recognized providers are trusted for
dismissal.

In `@backend/cliff/agents/triage_deep/runner.py`:
- Around line 91-107: The _kill_corroborated function uses overly permissive
checks on lines 101 and 104 that can cause false terminal clears of real
findings. For the duplicate_of_known kill class, the check only verifies that
any prior issue exists rather than confirming a prior issue actually matches the
current finding being evaluated. For the root_cause_in_nonship_code kill class,
the check clears if any candidate file matches an excluded pattern rather than
verifying the actual root cause file matches. Strengthen both conditions: for
duplicate_of_known, add logic to verify the prior_issues contain one that
corresponds to or matches the current threat context, and for
root_cause_in_nonship_code, modify the check to ensure only the true root cause
file (not just any candidate) is matched against the excluded_roots patterns.
This prevents unrelated findings from being incorrectly dismissed as terminal
clears.

In `@backend/cliff/agents/triage_runner.py`:
- Line 146: The finding parameter in the function signature on line 146 is typed
as Any, but it is used on lines 179-180 with the method call
finding.model_dump(...), which requires a concrete Pydantic model type. Replace
the Any type hint with the concrete finding or Pydantic model type returned by
get_finding to enable proper type checking and comply with the strict type hint
requirements for backend code.

In `@backend/cliff/api/routes/repos.py`:
- Around line 70-76: The call to get_repo_by_url(db, url) can raise
InvalidRepoUrlError for malformed input, but this exception is not being caught,
causing a 500 error instead of the appropriate 422 validation error response.
Wrap the get_repo_by_url call in a try-except block to catch InvalidRepoUrlError
and return a RepoProfileStatus with an appropriate error status (such as "error"
or "invalid") to properly handle client validation errors with a 422 response.

In `@backend/cliff/evals/cases.py`:
- Around line 80-85: Add validation to the EvalCase class to enforce the mutual
exclusivity constraint documented in the comments. Implement a validator (such
as a Pydantic validator or a __post_init__ method) that ensures either both repo
and sha are provided together (for deep dive live lane mode), or both are None
(for synthetic micro-repo mode with files). The validator should raise a clear
error if partial inputs are detected (e.g., repo without sha, or sha without
repo) or if repo/sha are provided alongside files, preventing silent fallbacks
to unintended evaluation modes.

In `@backend/cliff/evals/deep_dive_evaluators.py`:
- Around line 67-70: The code constructs a target path by joining repo with rel
without validating that the result stays within the repository bounds, allowing
citations to escape via absolute paths or parent directory traversal. After
constructing target from repo / rel, resolve both paths to their absolute forms
and verify that the resolved target path is contained within the resolved repo
directory before calling is_file(). Use pathlib methods like resolve() to get
canonical paths and ensure the target starts with or is relative to the repo
directory.

In `@backend/cliff/evals/runners.py`:
- Around line 401-404: The code at lines 401-404 directly writes files using
untrusted relative paths from case.files without validation, allowing path
traversal attacks (e.g., ../../../ or absolute paths) to escape the repo_dir
boundary. After computing fp = repo_dir / rel, resolve the path to its absolute
form and verify that the resolved path is still within repo_dir before creating
parent directories or writing content. Use pathlib operations like .resolve()
and check that the result starts with repo_dir.resolve() to ensure the file
stays within the intended repository boundary.
- Around line 371-387: The run_deep_dive_eval function currently allows empty
case lists and returns a passing result, while other eval runners in the module
hard-fail on empty datasets. Add an early validation check at the beginning of
run_deep_dive_eval (after the result initialization) that raises an appropriate
exception if the cases list is empty, making this function consistent with the
other eval runner functions in the module.

In `@backend/cliff/repos/git_ops.py`:
- Around line 48-50: The conditional check at lines 48-50 in the git_ops.py file
only verifies that a .git directory exists before calling refresh_repo, but does
not validate that the existing clone's origin remote URL matches the
canonical_url parameter. Add a check to verify that the origin URL of the
existing repository matches the canonical_url before deciding to refresh it. If
the origin does not match canonical_url, the existing clone should be removed
and a new clone from the correct canonical_url should be created instead of
calling refresh_repo.

In `@backend/cliff/repos/identity.py`:
- Around line 44-56: The code extracts only the hostname using parsed.hostname
on line 45, which discards port information and causes different URLs with
non-default ports to be treated identically. Replace the hostname extraction to
preserve port information by using parsed.netloc (which includes both hostname
and port) instead of parsed.hostname, then normalize it by converting to
lowercase. Update the assignment on line 45 where host is set and ensure the
port information is retained when the canonical URL is constructed on line 56 in
the return statement.

In `@backend/cliff/repos/repo_dir_manager.py`:
- Around line 72-85: The write_artifact and read_artifact methods in
repo_dir_manager.py currently handle all artifacts as raw dictionaries without
schema validation, allowing malformed data to be persisted and consumed
downstream. To fix this, modify write_artifact to validate the incoming data
parameter against the appropriate Pydantic model (RepoProfile, CodeMap, or
ThreatHistory depending on the artifact name) before calling _atomic_write_json,
and modify read_artifact to deserialize the JSON into the corresponding Pydantic
model instance and return that typed object instead of a raw dict. Map each
artifact name to its corresponding Pydantic model using a lookup structure, and
apply the same validation pattern to the affected code at lines 144-145.
- Around line 136-142: The _atomic_write_text function uses a fixed temporary
filename pattern where tmp is assigned using path.with_name(path.name + ".tmp"),
which causes collisions when multiple concurrent writes target the same file.
Replace this fixed naming scheme with a unique temporary file path per write
operation. Use a method like Python's tempfile module or generate a unique
identifier (such as UUID or process/thread ID) to create distinct temp filenames
for each write attempt, ensuring concurrent writers do not overwrite each
other's temporary files before the final os.replace operation.

In `@backend/cliff/repos/service.py`:
- Around line 73-91: The import of _github_token_from_integration, the
build_profile_runner call, and the asyncio.create_task scheduling block are all
unguarded and can raise exceptions that propagate to the caller, contradicting
the function's documented behavior. Wrap the entire code block from the import
statement through the final app.state.profile_tasks assignment in a try-except
block to catch any failures and log them instead of raising to the caller,
ensuring best-effort scheduling semantics are maintained.

In `@backend/tests/agents/test_model_tiers.py`:
- Line 18: The chained inequality assertion `assert ids["cheap"] !=
ids["strong"] != ids["judge"]` does not verify that all three tier IDs are
pairwise distinct; it only checks that cheap differs from strong AND strong
differs from judge, but not that cheap differs from judge. Replace this
assertion with a set cardinality check that converts the three ID values
(ids["cheap"], ids["strong"], ids["judge"]) into a set and verifies the set has
exactly 3 elements, ensuring all three tiers are truly distinct from one
another.

In `@frontend/src/components/issues/__tests__/IssueSidePanel.test.tsx`:
- Around line 1082-1107: The test data for DEEP_DIVE_TRIAGE includes a
repro_recipe with a docker_compose field set to null, but there is no
corresponding assertion verifying that this field is correctly rendered in the
TriageReproRecipe component. Add an assertion that validates docker_compose is
properly displayed or handled in the UI at both test locations (the anchor site
and the sibling site referenced in consolidated_sites) to close the contract gap
and catch future regressions in recipe field rendering.

In `@frontend/src/components/issues/IssueSidePanel.tsx`:
- Around line 1062-1098: The ReproRecipe function includes recipe.docker_compose
in the has visibility check but does not render its content in the JSX. Add a
conditional rendering block for docker_compose in the flex container (alongside
the existing blocks for image, setup, trigger, and expected_observation) to
display the docker_compose value when it exists, ensuring that valid recipe
details are not dropped from the UI and the visibility logic matches the actual
rendered content.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 19c611af-8573-438b-99d2-b6f53cc17d5e

📥 Commits

Reviewing files that changed from the base of the PR and between 6d0cffb and 2c3f73e.

📒 Files selected for processing (68)

• backend/cliff/agents/runtime/deps.py
• backend/cliff/agents/runtime/model_tiers.py
• backend/cliff/agents/runtime/tools/__init__.py
• backend/cliff/agents/runtime/tools/grep.py
• backend/cliff/agents/runtime/tools/read.py
• backend/cliff/agents/schemas.py
• backend/cliff/agents/triage_deep/__init__.py
• backend/cliff/agents/triage_deep/agents.py
• backend/cliff/agents/triage_deep/challenge.py
• backend/cliff/agents/triage_deep/escalation.py
• backend/cliff/agents/triage_deep/integration.py
• backend/cliff/agents/triage_deep/runner.py
• backend/cliff/agents/triage_runner.py
• backend/cliff/api/routes/agent_execution.py
• backend/cliff/api/routes/assessment.py
• backend/cliff/api/routes/repos.py
• backend/cliff/db/migrations/025_repo_entity.sql
• backend/cliff/evals/__init__.py
• backend/cliff/evals/cases.py
• backend/cliff/evals/deep_dive_evaluators.py
• backend/cliff/evals/repo_fetch.py
• backend/cliff/evals/runners.py
• backend/cliff/main.py
• backend/cliff/models/__init__.py
• backend/cliff/models/repo.py
• backend/cliff/repos/__init__.py
• backend/cliff/repos/clone.py
• backend/cliff/repos/dao.py
• backend/cliff/repos/gc.py
• backend/cliff/repos/git_ops.py
• backend/cliff/repos/identity.py
• backend/cliff/repos/knowledge.py
• backend/cliff/repos/profile_agents.py
• backend/cliff/repos/profile_runner.py
• backend/cliff/repos/repo_dir_manager.py
• backend/cliff/repos/schemas.py
• backend/cliff/repos/service.py
• backend/tests/agents/eval/triage_deep_dive.jsonl
• backend/tests/agents/test_deep_dive_agents.py
• backend/tests/agents/test_deep_dive_integration.py
• backend/tests/agents/test_deep_dive_runner.py
• backend/tests/agents/test_deep_dive_schemas.py
• backend/tests/agents/test_escalation.py
• backend/tests/agents/test_evals_deep_dive.py
• backend/tests/agents/test_grep_tool.py
• backend/tests/agents/test_model_tiers.py
• backend/tests/agents/test_read_budget.py
• backend/tests/agents/test_repo_fetch.py
• backend/tests/api/openapi_snapshot.json
• backend/tests/repos/__init__.py
• backend/tests/repos/conftest.py
• backend/tests/repos/test_clone.py
• backend/tests/repos/test_git_ops.py
• backend/tests/repos/test_identity.py
• backend/tests/repos/test_knowledge.py
• backend/tests/repos/test_profile_agents.py
• backend/tests/repos/test_profile_runner.py
• backend/tests/repos/test_repo_dao.py
• backend/tests/repos/test_repo_dir_manager.py
• backend/tests/repos/test_service.py
• backend/tests/test_routes_repos.py
• frontend/src/api/__tests__/repos.test.tsx
• frontend/src/api/client.ts
• frontend/src/api/repos.ts
• frontend/src/components/dashboard/ProjectProfileCard.tsx
• frontend/src/components/issues/IssueSidePanel.tsx
• frontend/src/components/issues/__tests__/IssueSidePanel.test.tsx
• frontend/src/pages/DashboardPage.tsx

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use a unique temp path per write; fixed *.tmp names can collide.

At Line 139, path.with_name(path.name + ".tmp") is shared by all concurrent writers to the same artifact. Two overlapping writes can clobber each other’s temp file and fail/lose updates before os.replace.

Suggested fix

+import tempfile
+
 def _atomic_write_text(path: Path, text: str) -> None:
     """Write *text* atomically — a concurrent reader sees old-or-new, never torn."""
     path.parent.mkdir(parents=True, exist_ok=True)
-    tmp = path.with_name(path.name + ".tmp")
-    tmp.write_text(text)
-    os.replace(tmp, path)
+    fd, tmp_name = tempfile.mkstemp(prefix=f".{path.name}.", suffix=".tmp", dir=path.parent)
+    try:
+        with os.fdopen(fd, "w", encoding="utf-8") as f:
+            f.write(text)
+        os.replace(tmp_name, path)
+    finally:
+        try:
+            os.unlink(tmp_name)
+        except FileNotFoundError:
+            pass

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/cliff/repos/repo_dir_manager.py` around lines 136 - 142, The
_atomic_write_text function uses a fixed temporary filename pattern where tmp is
assigned using path.with_name(path.name + ".tmp"), which causes collisions when
multiple concurrent writes target the same file. Replace this fixed naming
scheme with a unique temporary file path per write operation. Use a method like
Python's tempfile module or generate a unique identifier (such as UUID or
process/thread ID) to create distinct temp filenames for each write attempt,
ensuring concurrent writers do not overwrite each other's temporary files before
the final os.replace operation.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Best-effort scheduler still has unguarded exception paths.

This function documents “never raises into the caller,” but the import/runner construction/task scheduling block is outside try. Failures there can propagate to /assessment/run and break request handling.

Suggested fix

-    from cliff.api._engine_dep import _github_token_from_integration
-
-    runner = build_profile_runner(
-        db, model=model, token_provider=_github_token_from_integration
-    )
-
-    tasks: set[asyncio.Task[None]] = getattr(app.state, "profile_tasks", None) or set()
-
-    async def _run() -> None:
-        try:
-            await runner.build(repo_url)
-        except Exception:
-            logger.exception("eager profile build failed for %s", repo_url)
-
-    task = asyncio.create_task(_run(), name=f"profile:{repo_url}")
-    tasks.add(task)
-    task.add_done_callback(tasks.discard)
-    app.state.profile_tasks = tasks
-    return task
+    try:
+        from cliff.api._engine_dep import _github_token_from_integration
+
+        runner = build_profile_runner(
+            db, model=model, token_provider=_github_token_from_integration
+        )
+
+        tasks: set[asyncio.Task[None]] = getattr(app.state, "profile_tasks", None) or set()
+
+        async def _run() -> None:
+            try:
+                await runner.build(repo_url)
+            except Exception:
+                logger.exception("eager profile build failed for %s", repo_url)
+
+        task = asyncio.create_task(_run(), name=f"profile:{repo_url}")
+        tasks.add(task)
+        task.add_done_callback(tasks.discard)
+        app.state.profile_tasks = tasks
+        return task
+    except Exception:
+        logger.exception("profile build scheduling failed for %s", repo_url)
+        return None

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/cliff/repos/service.py` around lines 73 - 91, The import of
_github_token_from_integration, the build_profile_runner call, and the
asyncio.create_task scheduling block are all unguarded and can raise exceptions
that propagate to the caller, contradicting the function's documented behavior.
Wrap the entire code block from the import statement through the final
app.state.profile_tasks assignment in a try-except block to catch any failures
and log them instead of raising to the caller, ensuring best-effort scheduling
semantics are maintained.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Use a true pairwise-distinct assertion for three tiers.

Line 18 uses chained !=, which does not verify cheap != judge. For a “three distinct tiers” invariant, assert set cardinality instead.

Suggested fix

-    assert ids["cheap"] != ids["strong"] != ids["judge"]
+    assert len({ids["cheap"], ids["strong"], ids["judge"]}) == 3

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	assert ids["cheap"] != ids["strong"] != ids["judge"]
	assert len({ids["cheap"], ids["strong"], ids["judge"]}) == 3

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/tests/agents/test_model_tiers.py` at line 18, The chained inequality
assertion `assert ids["cheap"] != ids["strong"] != ids["judge"]` does not verify
that all three tier IDs are pairwise distinct; it only checks that cheap differs
from strong AND strong differs from judge, but not that cheap differs from
judge. Replace this assertion with a set cardinality check that converts the
three ID values (ids["cheap"], ids["strong"], ids["judge"]) into a set and
verifies the set has exactly 3 elements, ensuring all three tiers are truly
distinct from one another.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial | ⚡ Quick win

Add one assertion for docker_compose rendering in deep-dive recipe tests.

This closes a contract gap for TriageReproRecipe so regressions in recipe field rendering are caught early.

Suggested test update

 const DEEP_DIVE_TRIAGE = {
@@
         repro_recipe: {
           setup: ['pip install gradio'],
-          docker_compose: null,
+          docker_compose: 'docker-compose.yml',
           image: 'gradio:vuln',
           ports: [7860],
           trigger: ['curl "http://target/file=http://169.254.169.254/"'],
           expected_observation: 'metadata document returned',
         },
@@
   it('renders the exploit plan with its hypothesis + repro recipe', async () => {
@@
     expect(screen.getByText(/Reproduction recipe \(plan\)/)).toBeInTheDocument()
+    expect(screen.getByText(/docker compose:\s*docker-compose\.yml/i)).toBeInTheDocument()
   })

Also applies to: 1153-1161

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/components/issues/__tests__/IssueSidePanel.test.tsx` around
lines 1082 - 1107, The test data for DEEP_DIVE_TRIAGE includes a repro_recipe
with a docker_compose field set to null, but there is no corresponding assertion
verifying that this field is correctly rendered in the TriageReproRecipe
component. Add an assertion that validates docker_compose is properly displayed
or handled in the UI at both test locations (the anchor site and the sibling
site referenced in consolidated_sites) to close the contract gap and catch
future regressions in recipe field rendering.

[baz-reviewer]

_dataset_mode_invariant() only checks is None, so blank/whitespace repo/sha still reach checkout_at_sha() via run_deep_dive_eval() and fail later — should we reject or normalize empty strings here?

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents

Before applying, verify this suggestion against the current code. In
backend/cliff/evals/cases.py around lines 87-96, update EvalCase._dataset_mode_invariant
to treat repo/sha values that are empty or whitespace-only as missing (normalize to None
or raise a clear ValueError). Right now the validator only checks for None, so
whitespace strings can pass and later trigger infra failures when run_deep_dive_eval
tries to checkout. After normalization, re-apply the invariant: repo and sha must both
be provided together, and files must be mutually exclusive with real repo+sha. Ensure
the error messages mention that repo/sha cannot be blank.

Heads up!

Your free trial ends tomorrow.
To keep getting your PRs reviewed by Baz, update your team's subscription

[baz-reviewer]

The new deep-dive escalation block mirrors _run_scanner_triage, should we extract the shared best-effort pattern into a helper like _escalate_deep_dive(...) so future changes only land once?

Want Baz to fix this for you? Activate Fixer

Heads up!

Your free trial ends tomorrow.
To keep getting your PRs reviewed by Baz, update your team's subscription