chore(harbor): pin the default fork to 0ab5968 for the gemini flash fix

[RishiDesai]

Moves the default Harbor pin from f6b86c4 to 0ab5968 to pick up Harbor PR #16.

Why

Before that fix, Gemini CLI's legacy model resolution treated any model id ending in flash as a request for "the current flash model" and rewrote it to whatever the installed CLI considered current:

function isFlashModel(model) { return ... || model.endsWith("flash"); }
if (useGemini3_5Flash && isFlashModel(resolved) && ...) return DEFAULT_GEMINI_FLASH_MODEL;

So a trial submitted as google/gemini-3.6-flash silently ran on gemini-3.5-flash and recorded the wrong model in its trajectory — no error, no warning. Any Oddish trial on a *flash model id newer than the pinned CLI's built-in list was affected, with or without reasoning_effort.

Changes

The usual three files for a re-pin:

• oddish/src/oddish/config.py — HARBOR_DEFAULT_SHA, which Settings.harbor_source_ref derives from, so the probe ref moves with the worker image by construction
• oddish/uv.lock, backend/uv.lock — the resolved commit for the main-branch git source

The range from the previous pin (f6b86c4..0ab5968) touches only src/harbor/agents/installed/gemini_cli.py and its unit tests, so nothing else in the worker image changes.

Verification

The merge commit's tree is byte-identical to the fix commit that was smoke-tested (git diff 1dbf3e4e 0ab5968f is empty; both are tree 58020900), so the trial evidence applies exactly to this pin.

Oddish trial hello-world-b604edb0-124 (experiment 089dcded), submitted as google/gemini-3.6-flash with reasoning_effort=high on modal and pinned to harbor_sha 1dbf3e4e, finished success with reward 1.0. From the Gemini CLI's own session trajectory — its record of the model it actually called, not Oddish's submitted label:

"model":"gemini-3.6-flash"

ATIF trajectory.json agrees at agent.model_name and per-step. Across all artifacts pulled for that trial: 28 occurrences of gemini-3.6-flash, 12 of the Harbor alias gemini-3.6-flash-high, and zero of gemini-3.5-flash.

After the re-pin, the installed Harbor carries both parts of the fix (chat-base-3 inheritance and dynamicModelConfiguration), confirmed by inspecting GeminiCli._build_settings_config in the synced venv.

Tests

The pin-drift guards pass, including test_probe_harbor_ref_matches_pyproject_pin and the backend/uv.lock drift assertion in test_harbor_spec_parse.py (42 passed across test_harbor_* and test_probe_creds_injection.py). Both lockfiles validate under uv sync --frozen, which is what CI uses.

The full oddish/ suite reports the same 327 failures before and after this change — a byte-identical list, all from this sandbox having no Postgres. This re-pin introduces no new failures.

I reverted one piece of incidental collateral: re-locking with a newer uv also dropped the sys_platform markers from secretstorage's dependencies in both lockfiles. That is unrelated to the Harbor pin and would have changed install behavior on win32/emscripten, so the diff is now just the Harbor SHA in each lockfile.

  

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
oddish-app	Ready	Preview	Aug 1, 2026 1:38am

[github-actions]

Oddish preview

Commit: 4eb6941c65f53c52b1d9e5dff8ac5c8ce5c8067b

Surface	Link	Target
Frontend	https://pr-1029.oddish.app	Vercel preview for 4eb6941
Backend	oddish-pr-1029	oddish-pr-1029
Database	project ojzickkhlhocswdmqqul	project ojzickkhlhocswdmqqul

Vercel deployment URL: https://oddish-6lf8a1vcl.oddish.app

Plan:

• Frontend deploy: true
• Backend deploy: true
• Migrations: false

This comment is updated by the PR Preview workflow.