[Cedric Vidal (cedricvidal)]

Summary

Profile variation submissions could leak baseline profile-managed resource values into every variation, causing profiles with different bindings to conflict before comparative runs were created.

This change makes the API authoritative for profile fan-out. It rejects request-level profile-managed fields in variation mode, resolves each profile independently from the shared run intent, and keeps Portal and CLI submissions thin and consistent. It also documents the cross-client ownership invariant for future changes.

Closes #1613

Demos

Before

Baseline profile resources are copied into shared request state and conflict with the comparison profile.

before-profile-variation.mp4

After

The API creates two isolated requests whose persisted resource values come from their respective profiles.

after-profile-variation.mp4

Testing

• pnpm exec vitest run apps/api/src/endpoints.test.ts apps/cli/src/commands/run.test.ts apps/portal/src/pages/SubmitRun.variations.test.tsx --reporter=default - passed, 188 tests
• pnpm --filter api build - passed
• pnpm --filter cli build - passed
• pnpm --filter portal build - passed
• git diff --check - passed
• Docker Compose API and Portal readiness checks - passed
• Live API verification confirmed the baseline and comparison requests share one submission ID while persisting baseline/repository and comparison/repository independently

Documentation and compatibility

Updated docs/architecture/app-design.md, docs/architecture/resources.md, and AGENTS.md to document API-owned fan-out and profile isolation.

Variation-mode API submissions now reject request-level worker, model, reasoning effort, agent version, MCP server, skill, extension, and resource fields. This is an intentional contract tightening that prevents ambiguous shared/profile state. Single-profile submissions are unchanged. No migration, dependency, or upgrade steps are required.

Checklist

• If Portal features changed, keep CLI capabilities in sync.
• If Portal components changed, update their Storybook stories. (N/A - no reusable component changed; page submission behavior is covered by Vitest.)
• If database changes require a migration, include up() / down() and keep it CosmosDB-compatible. (N/A - no database changes.)
• If dependencies changed, update the lockfile and regenerate NOTICE / NOTICE-REVIEW.txt with pnpm notice as needed. (N/A - no dependency changes.)
• Video showing the behavior before the suggested change
• Video showing the behavior after the suggested change