• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Best possible solution:

Merge after maintainers accept non-declarative Foundry overlays and the exported input type shape; otherwise close this PR as superseded by #83267.

Do we have a high-confidence way to reproduce the issue?

Yes, by source inspection. Current main validates built-in timeout overlays and its Foundry test expects a timeout-only entry to synthesize a selected model, which is the behavior this PR intentionally changes.

Is this the best way to solve the issue?

Yes, with maintainer acceptance. The PR keeps the merged schema validation boundary and narrows Foundry mutation instead of adding another config path, but the compatibility semantics are a product/owner decision.

Label justifications:

• P2: Provider timeout overlay behavior is a normal-priority config/provider fix with limited but real model-provider impact.
• merge-risk: 🚨 compatibility: The PR changes current-main Microsoft Foundry overlay behavior for existing timeout-only configs.
• merge-risk: 🚨 auth-provider: The PR deliberately prevents overlay-only Foundry configs from rebinding auth/profile metadata during model selection.
• rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🦞 diamond lobster, patch quality is 🐚 platinum hermit, and Strong terminal proof supports a focused patch, with merge readiness depending mainly on maintainer acceptance of the compatibility semantics.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body includes after-fix terminal CLI config validation proof for accepted and rejected provider-overlay configs plus focused test, type, format, and diff-check output.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix terminal CLI config validation proof for accepted and rejected provider-overlay configs plus focused test, type, format, and diff-check output.

What I checked:

• PR diff changes Foundry selection semantics: The PR patch adds a guard so Microsoft Foundry onModelSelected returns unless the provider config has a non-empty baseUrl and a models array, preventing timeout-only overlays from synthesizing provider declarations. (extensions/microsoft-foundry/provider.ts:27, 0f215f508789)
• Current main already validates built-in timeout overlays: Current main makes model provider baseUrl/models optional in the schema, allows built-in provider overlay IDs, and still requires baseUrl/models for custom providers. (src/config/zod-schema.core.ts:432, b33deb41594e)
• Current main materializes built-in overlays: Current main normalizes built-in overlay entries by filling missing baseUrl with an empty string and missing models with an empty array after schema validation. (src/config/validation.ts:79, b33deb41594e)
• Current main prevents generic fallback synthesis without provider surface: The model resolver only treats configured fallback as available for mock models, explicit configured models, or provider configs with a non-empty baseUrl. (src/agents/pi-embedded-runner/model.ts:450, b33deb41594e)
• Merged provenance for the central timeout-overlay fix: Merged pull request fix(config): allow bundled provider timeout overlays #83267 introduced the current built-in provider overlay validation/materialization and fallback guard behavior that this PR refines. (src/config/zod-schema.core.ts:432, ff871e162aaf)
• Real behavior proof in PR body: The PR body reports terminal proof with real config validate commands for accepted built-in overlays and rejected unknown-provider overlays, plus focused Vitest, tsgo, format, and diff-check runs. (0f215f508789)

Likely related people:

• giodl73-repo: Authored merged pull request fix(config): allow bundled provider timeout overlays #83267, which introduced the current provider timeout overlay validation, materialization, Foundry tolerance, and fallback guard behavior this PR refines. (role: introduced current timeout-overlay behavior and follow-up author; confidence: high; commits: ff871e162aaf, 1843302542bc; files: src/config/zod-schema.core.ts, src/config/validation.ts, src/agents/pi-embedded-runner/model.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against b33deb41594e.

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.