Collapse the six colour schemes to the one granted accent, API first

[thomasluizon]

Closes the orbit-api half of thomasluizon/orbit-tickets#367.

What changes

The API keeps accepting and returning colorScheme, and the value stops meaning anything. The write stores the one granted accent, and every read path reports it.

Round 2: the three review findings

The first head resolved every read to ColorSchemes.Granted but left the write storing the requested key, so the read and the write disagreed. This head closes that and the two findings under it.

1. The write now collapses too. User.SetColorScheme still accepts all six historical keys, so no shipped client gets a 400, and stores ColorSchemes.Granted instead of the request. A PUT of "blue" now stores "orange", the refetch answers "orange", and the accent no longer snaps back on the live 1.3.31 build. A null request still clears the preference, because no read surfaces the stored value and writing one on a clear would only add data nobody reads.
2. The data export tells the truth again. ExportUserDataQuery goes back to user.ColorScheme. A subject access export answers what the database holds, not what the app draws, and no migration rewrites rows written before the collapse, so a row holding 'rose' exports 'rose'. After the write collapse a row the current API writes holds the granted accent anyway, so the two agree for every new write and the export stays honest for the old ones. The catalog sentence on the same field was left contradicting that export, which round 3 below fixes.
3. AgentContextSnapshot.ColorScheme is deleted. Pinning it to a constant made Color scheme: orange a literal line in every prompt for every account, made the ?? "default" branch unreachable, and declared a nullability the code could no longer produce. The field, its prompt line in AgentCatalogService.cs, and the argument in ProcessUserChatCommand.Ai.cs are gone.

Also taken, since it was two lines: ColorSchemes.AcceptedValues is a FrozenSet<string> rather than a publicly mutable string[], so no assembly can rewrite the domain validation rule for the process.

Round 3: the catalog sentence the export contradicts

The review at head d652a1fd verified all three round 2 fixes and left one finding.

AgentCatalogService.UserDataCatalog.cs:41 read "Orbit uses one accent, so every account reads back the same value". The export on the same field deliberately returns the raw column, so an account whose row holds 'rose' could ask Astra what Orbit stores and hear orange, then download the export and read rose. Two Orbit surfaces answered one question two ways.

The entry now states both halves:

Accent color scheme. Orbit renders one accent, so the profile always reads back the granted value; a row written before the collapse still holds its original key.

The sweep found no twin carrying that claim. The new test walks every data catalog entry and field, every capability, every app surface, every chat tool description and every MCP tool description, keeps the ones that mention the colour scheme, and fails on any universal sameness claim. With the old string in place it named exactly one offender, data catalog profile.ColorScheme. Nothing else stated it.

The sweep did surface a second inaccuracy of the same family, on the write rather than the read. Three sentences said "store the user's color scheme preference" while round 2 made the write store the granted value. An agent reading one of them would tell a person their chosen key was kept. All three now say the value is accepted from an older app and the stored one becomes the granted one:

• src/Orbit.Api/Mcp/Tools/ProfileTools.cs, the set_color_scheme tool description.
• src/Orbit.Application/Chat/Tools/Implementations/ProfileTools.cs, the chat tool twin of the same sentence.
• src/Orbit.Infrastructure/Services/AgentCatalogService.Capabilities.cs, the Write Premium Appearance capability description.

Why it is expand-contract and not a delete

colorScheme is a shipped DTO field and mobile lags through the Play store, so CLAUDE.md makes shared and DTO changes append-only and deploy-API-first. This pull request therefore does none of the things that would break an old client:

• No field on a wire contract is removed, renamed or retyped. ProfileResponse.ColorScheme, ExportedSettings.ColorScheme and both request records keep their shape, and src/Orbit.Api/openapi.json is byte identical. AgentContextSnapshot is an internal prompt model that never appears in openapi.json, which is why deleting a field on it is safe here.
• set_color_scheme still exists on the controller, the chat tool and the MCP tool, and still returns success for all six historical values and for null.
• All six values stay writable. User.SetColorScheme still rejects an unknown value with INVALID_COLOR_SCHEME.
• No migration runs. Rows written before this deploy are untouched, so reverting this pull request restores the old behaviour with every one of those rows intact. That is the kill switch.

The union narrows later, once AppConfig.MinSupportedVersion covers the narrowed clients, which is the contract step this ticket deliberately defers.

Why the resolved value is the string orange

Verified against the shipped client source on orbit-ui-mobile main, not from memory:

• packages/shared/src/theme/color-schemes.ts maps orange to #ff6900 / #f54900, the only warm orange of the six, and every other key to a different hue.
• packages/shared/src/utils/upgrade.ts:62 sets DEFAULT_FREE_COLOR_SCHEME = 'purple', and resolveAccessibleColorScheme returns it whenever colorScheme is null.

So returning null would have rendered purple on every shipped build. Returning orange renders warm orange there, and the redesign client already maps all six keys to the granted #C4530F.

Assumptions

• A null write clears the stored preference instead of storing the granted accent. The rejected alternative was to read "store the granted value whatever arrives" literally and write "orange" on a clear. Both give the same round trip, because the read reports the granted accent either way, and clearing writes no value that any read surfaces.
• The export reports the raw stored value rather than the granted accent. The rejected alternative was to keep the constant and let the export agree with the profile read. It was rejected because an export answers what is stored, and a pre collapse row still holds a retired key.
• The round 3 test asserts prose, because the finding is about a sentence. It is pinned to the load bearing claim only: the entry may not contain "the same value", and must name the pre collapse row with original, pre-collapse or before the collapse. The rejected alternative was to assert the whole sentence byte for byte, which would break on any harmless rewording.
• The legacy row fixture reaches User.ColorScheme through its private setter by reflection, in tests/Orbit.Application.Tests/Common/LegacyUserRows.cs. The rejected alternative was to build the fixture through SetColorScheme, which no longer produces a retired key and would have made the export and profile tests vacuous.
  I mocked the new IHabitLogReader constructor argument instead of changing production behavior.

Test evidence

Finding 1, the read and the write disagreeing

Existing tests, unchanged, with the defect present. The round trip was uncovered, exactly as the review said.

dotnet test tests/Orbit.Application.Tests --filter "FullyQualifiedName~ColorScheme"
Aprovado! Com falha: 0, Aprovado: 34, Ignorado: 0, Total: 34

All 34 passed with the defect present, because every one of them exercises the read or the write alone.
Strengthened test, with the defect still present. tests/Orbit.Application.Tests/Behaviors/ColorSchemeRoundTripTests.cs drives the real SetColorSchemeCommandHandler and then the real GetProfileQueryHandler over the same user, and asserts the read equals what the write stored.

dotnet test tests/Orbit.Application.Tests --filter "FullyQualifiedName~ColorSchemeRoundTripTests|FullyQualifiedName~ExportUserDataQueryHandlerTests"
Com falha! Com falha: 11, Aprovado: 15, Ignorado: 0, Total: 26
Expected read.Value.ColorScheme to be "purple", but "orange" differs near "ora" (index 0).

Five of the six historical values failed. The orange case passed, correctly, because it already resolved to itself.
After the fix. Green, with the whole colour scheme filter:

dotnet test tests/Orbit.Application.Tests --filter "FullyQualifiedName~ColorScheme"
Aprovado! Com falha: 0, Aprovado: 40, Ignorado: 0, Total: 40

Finding 2, the export

Existing test, unchanged, with the defect present. Handle_StoredHistoricalColorScheme_ExportsGrantedAccent asserted the wrong behaviour and passed on the first head, inside the 34 above.
Strengthened tests, with the defect still present. Turned around into Handle_LegacyStoredColorScheme_ExportsTheStoredValueNotTheGrantedAccent and Handle_NoStoredColorScheme_ExportsNull, in the same run as above:

Expected result.Value.Settings.ColorScheme to be "rose" with a length of 4, but "orange" has a length of 6, differs near "ora" (index 0).
Handle_NoStoredColorScheme_ExportsNull [FAIL]

Six failures, the five retired keys plus the untouched account. Handle_ColorSchemeWrittenByTheCurrentApi_ExportsTheGrantedAccent pins the other side: a row the current API writes exports the granted accent.
After the fix. Green, inside the 40 above.

Finding 3, the domain guard

tests/Orbit.Domain.Tests/Entities/UserColorSchemeTests.cs is new and covers the mutator directly. With the defect present:

dotnet test tests/Orbit.Domain.Tests --filter "FullyQualifiedName~UserColorSchemeTests"
Com falha! Com falha: 6, Aprovado: 3, Ignorado: 0, Total: 9

After the fix, 9 of 9 pass.

Round 3, the catalog sentence

Existing tests, unchanged, with the defect present. Nothing covered the agreement between the two surfaces.

dotnet test tests/Orbit.Application.Tests --filter "FullyQualifiedName~ExportUserDataQueryHandlerTests"
Aprovado! Com falha: 0, Aprovado: 19, Ignorado: 0, Total: 19
dotnet test tests/Orbit.Infrastructure.Tests --filter "FullyQualifiedName~AgentCatalogServiceTests"
Aprovado! Com falha: 0, Aprovado: 11, Ignorado: 0, Total: 11

Both green with the false sentence in place.
Strengthened tests, with the defect still present. ExportUserDataQueryHandlerTests.Handle_LegacyStoredColorScheme_AgreesWithTheUserDataCatalogEntry runs the real ExportUserDataQueryHandler over a row holding 'rose', then reads the real AgentCatalogService entry for the same field:

dotnet test tests/Orbit.Application.Tests --filter "FullyQualifiedName~Handle_LegacyStoredColorScheme_AgreesWithTheUserDataCatalogEntry"
Com falha! Com falha: 1, Aprovado: 0, Ignorado: 0, Total: 1
Did not expect meaning to contain the equivalent of "the same value" because the export
returns the stored key, so the catalog cannot promise one value for every account but found
"Accent color scheme. Orbit uses one accent, so every account reads back the same value.".

AgentCatalogServiceTests.NoAgentFacingColorSchemeText_PromisesOneStoredValueForEveryAccount is the sweep, and it names the offending surface rather than only failing:

dotnet test tests/Orbit.Infrastructure.Tests --filter "FullyQualifiedName~NoAgentFacingColorSchemeText_PromisesOneStoredValueForEveryAccount"
Com falha! Com falha: 1, Aprovado: 0, Ignorado: 0, Total: 1
Expected contradictingTheExport to be empty, but found at least one item
{"data catalog profile.ColorScheme"}.

That one item is the sweep result: one offender, no twin.
After the fix. Both green, together with every neighbouring colour scheme test:

dotnet test tests/Orbit.Application.Tests --filter "FullyQualifiedName~ExportUserDataQueryHandlerTests|FullyQualifiedName~ColorSchemeRoundTripTests"
Aprovado! Com falha: 0, Aprovado: 27, Ignorado: 0, Total: 27
dotnet test tests/Orbit.Infrastructure.Tests --filter "FullyQualifiedName~AgentCatalogServiceTests|FullyQualifiedName~ProfileToolsTests"
Aprovado! Com falha: 0, Aprovado: 29, Ignorado: 0, Total: 29

Full suite

Suite	Result
Build Orbit.slnx	0 errors, pre existing warnings only
src/Orbit.Api/openapi.json staleness	clean, no diff
Orbit.Analyzers.Tests	32 passed, 0 failed
Orbit.Domain.Tests	594 passed, 0 failed
Orbit.Application.Tests	3425 passed, 0 failed
Orbit.Infrastructure.Tests	2236 passed, 0 failed
Dash Ban on changed files, dash baseline, root allowlist, suppression allowlist	clean
dotnet format --verify-no-changes on every changed file	clean
Bare comment grep over every changed .cs file	only the three pre existing #pragma lines in AgentCatalogService.cs, already in the allowlist
architecture.json and architecture.html moved in the round 2 commit because two new test classes entered the map. They are regenerated by node tools/arch-map.mjs and committed with that source change. Round 3 changes only strings and tests, so a rerun of the generator leaves both files untouched.

Tests that moved with the contract

ProfileCommandHandlerTests.SetColorScheme_Valid_StoresTheGrantedAccentAndSaves, SetColorSchemeCommandHandlerTests.Handle_ConcurrencyConflictThenSuccess_ResolvesToSuccessAndKeepsLastWrite, ApplyOnboardingCommandHandlerTests, AgentCatalogServiceTests and AgentSessionAndSyncEntityTests all encoded either the passthrough write or the snapshot field. Each now asserts the collapsed behaviour.
dotnet build Orbit.slnx: 0 errors; 184 focused tests passed; EF found no pending changes; full suite: 6,575 passed.
The default locale caused nine failures; one unrelated timestamp test failed once, then passed unchanged (filed as thomasluizon/orbit-tickets#676).

Deliberately not changed

• The Pro pay gate on set_color_scheme. CanManagePremiumColors still gates the write, and the capability still declares planRequirement: "Pro". Removing it would move the generated gating matrix and the agent capability contract for no user visible gain, since the client half deletes the picker anyway.
• The free account purple split recorded in the review at apps/mobile/stores/auth-store.ts:409. It belongs to the client repository and it disappears when redesign/main collapses color-schemes.ts.

What this half cannot deliver on its own

On a shipped build, resolveAccessibleColorScheme forces a free account back to purple whatever the API returns. So after this deploys, every Pro account on a shipped build and every account on a redesign build renders the granted accent, and free accounts on shipped builds stay purple until the client half of #367 ships. That is the shipped client's own pay gate, not a gap in this pull request.

Merging is not deploying. The client half waits on this being live.

Manual steps

• When the redesign ships: once the redesign Android build is live on the Play track, raise AppConfig.MinSupportedVersion to it, so no supported client still offers the six paid colour schemes this API collapses (Pullfrog P1 on User.cs:248, 2026-09-25).
  None. No environment variable, no console setting and no backfill. The behaviour is live the moment the deploy completes.
  🤖 Generated with Claude Code
  Closes thomasluizon/orbit-tickets#367.
  None.

[pullfrog]

Run failed. View the logs →

  ^{｜ Rerun failed job ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using GPT Sol ｜ 𝕏}

[pullfrog]

Warning

Your Claude subscription has reached its usage limit, and you have no OpenAI key for the primary model.

Every Pullfrog run on thomasluizon has failed since September 18 (5 runs, no successes), so this review did not happen.

Anthropic returns "The usage limit has been reached" for your Claude Pro/Max subscription, which means you've hit the plan's monthly or hourly cap. The workflow falls back to Claude because there is no OpenAI API key stored for the primary GPT Sol model.

To fix it:

1. Add an OpenAI API key on the BYOK tab of your Billing card so the primary model can run without relying on the Claude fallback.
2. If you want to keep using Claude when your OpenAI runs hit limits, add an Anthropic API key alongside your subscription — the setup docs show how.

[thomasluizon]

Independent review at head 2b41b856: REQUEST CHANGES. This pull request had never been reviewed by anyone.

Codex and Pullfrog share one exhausted OpenAI allowance until 2026-09-22, so a separate Claude agent reviewed this and the orchestrator verified every load-bearing claim below against the tree. Stating the substitution rather than hiding it: this is not a Pullfrog verdict and it does not publish pullfrog-approval, which this pull request still needs before it can merge to protected main.

The database side is clean and deliberate. Nothing is dropped, renamed or retyped. User.cs:212-213 still accepts all six through ColorSchemes.AcceptedValues, ProfileResponse.ColorScheme is still string?, OrbitDbContext.cs:694 is unchanged, and the diff touches zero files under src/Orbit.Infrastructure/Migrations/. The stored row is never rewritten, so the revert is a three-line change. The client contract is also safe: packages/shared/src/types/profile.ts:76 declares colorScheme: z.string().nullable(), not a Zod enum, so "orange" parses on every shipped client and nothing throws.

The defect is on the behaviour side.

1. High: the read and the write now disagree, so the live picker silently discards the choice

GetProfileQuery.cs:140 returns ColorSchemes.Granted, while ProfileController.cs:209-217 and User.cs:209-215 still accept and STORE all six and answer 204.

A Pro user on the live 1.3.31 build taps Blue. apps/mobile/lib/theme-provider.tsx:217-228 patches the cache optimistically and PUTs; the PUT succeeds so the catch rollback at :223 never runs and the server stores "blue". The next profile fetch returns "orange", apps/mobile/lib/resolve-active-scheme.ts:15 yields "orange", and theme-provider.tsx:178-181 writes it back. The accent snaps back and the tap did nothing.

Verified against origin/main, the tree that built 1.3.31, not against redesign/main: packages/shared/src/theme/color-schemes.ts there defines six DISTINCT accents, purple #7f46f7 against orange #ff6900. So this is visible on the shipped build, not only in theory. On redesign/main the same file already maps all six keys to the one granted accent, which is why the redesign client is unaffected.

The web path also rewrites persisted client state: apps/web/hooks/use-profile.ts:49 calls syncSchemeFromProfile on every load and apps/web/hooks/use-color-scheme.ts:75-87 rewrites the orbit_color_scheme cookie.

No test in the repository covers the round trip. Nine test files mention ColorScheme and every one exercises the read or the write alone.

The fix, and it is the ticket's own intent carried through: collapse the WRITE as well. Keep accepting all six so no shipped client gets a 400, and store ColorSchemes.Granted whatever arrives. #367 scope item 1 says "keep accepting and returning colorScheme for old clients, and stop it meaning anything: every value resolves to the one scheme", and a write that still means something is the half that was left. D69 deleted colour as data, so preserving the raw value "for a clean revert" is buying a revert nobody is going to run at the cost of an endpoint that contradicts itself.

Cover it with the round trip that fails today:

user.SetColorScheme("rose");
var result = await _handler.Handle(new GetProfileQuery(UserId), CancellationToken.None);
result.Value.ColorScheme.Should().Be(result of the write, not a third value);

2. High: the data export states something the database does not hold

ExportUserDataQuery.cs:92 replaces user.ColorScheme with ColorSchemes.Granted. A user whose row holds 'rose' requests an export and the JSON says "colorScheme": "orange", while this pull request's own doc comment on User.cs:82 says the raw value is kept untouched.

A subject-access export answers "what do you store about me", never "what does the app draw". AgentCatalogService.UserDataCatalog.cs:41 still declares the field exportable, and the exportable half is now false.

Revert that line to user.ColorScheme. The new test Handle_StoredHistoricalColorScheme_ExportsGrantedAccent asserts the wrong behaviour; turn its assertion around and it fails on this head at once.

If item 1 is taken and the write collapses, this resolves itself, because the stored value and the granted value become the same thing. Do item 1 first, then re-read this one.

3. Medium: the chat snapshot is now a constant in every prompt for every user

ProcessUserChatCommand.Ai.cs:125 changes hasProAccess ? user?.ColorScheme : null to an unconditional ColorSchemes.Granted, and AgentCatalogService.cs:110 renders Color scheme: {snapshot.ColorScheme ?? "default"} into every agent supplement. That line is now the literal text Color scheme: orange on every message for every account, the ?? "default" branch is unreachable, and AgentContracts.cs:206 still declares string? ColorScheme, a nullability the code can no longer produce.

Code standard 2 is delete unused code rather than pin it. Remove ColorScheme from AgentContextSnapshot and from AgentCatalogService.cs:110.

4. Low, and it belongs to the UI half of #367, not to this pull request

apps/mobile/stores/auth-store.ts:409 and :494 set the module-level runtime scheme straight from the response with NO Pro gate, while apps/mobile/lib/theme-provider.tsx:176 routes the same field through resolveAccessibleColorScheme, which does gate and returns 'purple' for a free account. Before this change a free account's colorScheme was almost always null so both paths agreed. After it, on a client whose six schemes are still distinct, a free account gets a purple app and an orange error boundary.

It disappears the moment #367 scope item 2 collapses color-schemes.ts, which redesign/main has already done. Recorded here so it is not lost; do not widen this pull request for it.

Verified clean, with the evidence

• Every read path is covered. GetProfileQuery.cs:140, ExportUserDataQuery.cs:92, ProcessUserChatCommand.Ai.cs:125, the chat ProfileTools payload and the MCP ProfileTools message. No raw value leaks through a path the pull request missed. There is no sync read of the field: packages/shared/src/types/sync.ts:10 lists setColorScheme as a mutation only.
• Bare comments: none. The diff adds five comment blocks to .cs files and all five are /// XML-doc. NoCommentsAnalyzer.cs:48-52 inspects only SingleLineCommentTrivia and MultiLineCommentTrivia; SingleLineDocumentationCommentTrivia is a different kind and the analyzer's own summary at :10-11 says XML-doc is allowed. This matters because ORBIT0001 does not run under the locally installed SDK.
• DateTime.UtcNow: one new use, and it needs no suppression. UtcNowUserFacingDateAnalyzer.cs:46-51 limits itself to Orbit.Api, Orbit.Application, Orbit.Domain and Orbit.Infrastructure, and :66 returns early otherwise. The new call is in Orbit.Application.Tests.
• No vacuous test among the eight. Each one was checked by naming the revert that makes it red. One weak row, not a finding: the [InlineData(null)] case asserts null on a fresh User.Create where null is already the default, and stays green even if SetColorScheme no-ops on null; the _unitOfWork.Received(1) assertion and the six non-null rows cover it.
• Naming, swallowed Result failures, trust-boundary validation: all clean.

One note, not a finding: ColorSchemes.AcceptedValues is a publicly mutable static array. readonly protects the reference and not the six elements, so any assembly can rewrite the domain validation rule for the process. No caller mutates it today. FrozenSet<string> or ImmutableArray<string> is the shape.

[pullfrog]

Run failed. View the logs →

  ^{｜ Rerun failed job ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using GPT Sol ｜ 𝕏}

[pullfrog]

Run failed. View the logs →

  ^{｜ Rerun failed job ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using GPT Sol ｜ 𝕏}

[thomasluizon]

Independent review, head d652a1fdc159afccf6a4e6c61c8bfe6480fb4779

Pullfrog could not run this review. Codex and Pullfrog share one OpenAI meter and it is exhausted until 2026-09-22 07:23; five Pullfrog runs on this pull request failed for that reason and pullfrog-approval is absent from the rollup. A separate agent reviewed instead, in the worktree carrying this exact head, and the full result is posted here rather than summarized. The substitution is named so nobody later reads this as having had the usual reviewer.

Verdict: APPROVE. All three earlier findings are genuinely fixed, and the red-first claim was verified independently: each defect was restored in an isolated git archive copy and the new tests were observed to go red. The reviewed worktree was never written to, and git status --porcelain was empty before and after. Two findings remain and neither is a defect a person hits.

---

Earlier findings

#	Finding	Status	Evidence
1, High	The read returned the granted constant while the write stored all six, so the live 1.3.31 picker discarded the choice	Fixed	src/Orbit.Domain/Entities/User.cs:224 stores colorScheme is null ? null : ColorSchemes.Granted, and GetProfileQuery.cs:140 returns ColorSchemes.Granted. Write and read agree. Restoring the old write reddened 6 of 9 domain tests and 14 of 40 application tests, including ColorSchemeRoundTripTests.SetThenGet_ReturnsTheValueTheWriteStored. Restoring the old read reddened 8, including the null case.
2, High	The export stated a value the database does not hold	Fixed	ExportUserDataQuery.cs:92 is back to user.ColorScheme and the file has left the diff. Re-applying the constant in a copy reddened 6 tests, five legacy keys plus Handle_NoStoredColorScheme_ExportsNull.
3, Medium	The chat snapshot pinned the scheme to a constant in every prompt	Fixed	The parameter is gone from AgentContracts.cs:203, the prompt line from AgentCatalogService.cs:110, the argument from ProcessUserChatCommand.Ai.cs:125. AgentContextSnapshot appears zero times in src/Orbit.Api/openapi.json and in no controller, so the deletion touches no wire contract.
note	AcceptedValues publicly mutable	Fixed	ColorSchemes.cs:24 is a FrozenSet<string> with StringComparer.Ordinal, the same comparison string[].Contains used, so "Blue" is still rejected.
recorded, not this repository	An ungated runtime scheme in the mobile client	Still open	Confirmed live on orbit-ui-mobile origin/main: apps/mobile/stores/auth-store.ts:240 and :302 set the runtime theme from profile.colorScheme with no Pro gate, while apps/mobile/lib/theme-provider.tsx:87 routes it through resolveAccessibleColorScheme, which forces 'purple' for a free account. This deploy makes that fire for every free account instead of almost none. #367 scope item 2 closes it.

Nothing regressed.

New findings

P2. The catalog string is false for exactly the rows the export now reports truthfully

src/Orbit.Infrastructure/Services/AgentCatalogService.UserDataCatalog.cs:41 now reads "Orbit uses one accent, so every account reads back the same value". The export on the same field deliberately returns the raw column.

An account whose row was written before this deploy holds 'rose'. The person asks Astra what colour scheme Orbit stores for them. Astra calls list_user_data_catalog_v2 at src/Orbit.Api/Mcp/Tools/AgentTools.cs:30, also reachable through AiController.GetUserDataCatalog, reads that sentence, and answers orange. The person downloads their data export and the JSON says "colorScheme": "rose". Two Orbit surfaces disagree about one stored field, at the exact line round 2 named for this class of defect.

AgentCatalogService.UserDataCatalog.cs is already in this diff, so under "Maximum implementation" the string belongs in this pull request rather than a follow-up.

Fix: one string, true of both surfaces. For example: "Accent color scheme. Orbit renders one accent, so the profile always reads back the granted value; a row written before the collapse still holds its original key."

P3. The pay gate still upsells an inert preference

src/Orbit.Application/Common/PayGateService.cs:170: CanManagePremiumColors still answers "Premium color schemes are a Pro feature. Upgrade to unlock!" for a write that the capability description one file away now says "does not change how anything looks". A free account asking Astra to change the accent is upsold to Pro for a preference that does nothing.

The pull request body gives its reason, that removing the gate moves the generated gating matrix and the capability contract, and that reasoning holds: it belongs in a follow-up ticket rather than here.

---

Checked and clean

• Every reader of the value, enumerated from a full-tree grep. GetProfileQuery.cs:140 granted, ExportUserDataQuery.cs:92 raw by design, the chat tool payload at Chat/Tools/Implementations/ProfileTools.cs:152 granted, the MCP message at Api/Mcp/Tools/ProfileTools.cs:122 granted, and the chat snapshot deleted. No projection, cache, sync DTO or email template reads the field; the SyncController "color" hits are tag colours.
• Contract. src/Orbit.Api/openapi.json is untouched and a full solution build left it unmodified, so the staleness gate is satisfied. colorScheme is still ["null","string"] in ProfileResponse and SetColorSchemeRequest. No migration in the diff. packages/shared/src/types/profile.ts:51,126 declares z.string().nullable() and not an enum, so "orange" parses on the live 1.3.31 build.
• "orange" is the right constant, verified against orbit-ui-mobile origin/main: packages/shared/src/theme/color-schemes.ts:53-56 maps orange to #ff6900 and #f54900, the only warm orange of the six, and packages/shared/src/utils/upgrade.ts:161 returns 'purple' for null, so returning null would have painted purple everywhere.
• No new test is a tautology. Each was checked by restoring the defect, not by reading its name. The three mutation-testing jobs are green.
• Comments. Every changed .cs file was read by eye, since ORBIT0001 does not run under the locally installed SDK. The only // hits are three pre-existing #pragma warning disable trailers in the AgentCatalogService partials, on unchanged lines. Everything added is /// XML doc, which NoCommentsAnalyzer.cs:48-49 never inspects.
• Authorization, error handling, naming, dead code. Unchanged caller-id plumbing, a real Result.Failure on an unknown key with nothing swallowed, descriptive names, nothing left behind.
• CI. Every check is SUCCESS: Build, Unit Tests, OpenAPI Breaking-Change Gate, Gating matrix drift, arch-map drift, Dash Ban, Root Allowlist, CodeQL and SonarCloud at 93.8% coverage on new code.

Commands run

git -C <worktree> rev-parse HEAD                        -> d652a1fdc159afccf6a4e6c61c8bfe6480fb4779
dotnet build Orbit.slnx                                 -> 0 errors, 9 pre-existing NU1608/CS9057 warnings
dotnet test tests/Orbit.Domain.Tests                    -> 594 passed, 0 failed
dotnet test tests/Orbit.Application.Tests               -> 3424 passed, 0 failed
dotnet test tests/Orbit.Infrastructure.Tests            -> 2235 passed, 0 failed
dotnet test tests/Orbit.Analyzers.Tests                 -> 32 passed, 0 failed
dotnet test tests/Orbit.Application.Tests --filter ColorScheme -> 40 passed, 0 failed
red-first in a git archive copy: write mutant          -> domain 6/9 failed, application 14/40 failed
                                 export mutant         -> 6/19 failed
                                 read mutant           -> 8/40 failed
                                 chat payload, MCP msg -> 1 failure each, both the new tests
node tools/check-dashes.mjs --files / --check-baseline / --text "<PR title> <PR body>" -> exit 0
node tools/check-root-allowlist.mjs                     -> exit 0
node tools/arch-map.mjs in an isolated copy             -> architecture.json and .html md5 identical, no drift
git status --porcelain in the worktree, before and after -> empty

This pull request cannot merge before 2026-09-22 in any case, because it targets protected main where pullfrog-approval is required. A round for the P2 above is ordered on #367; everything else here is merge-ready.

[pullfrog]

Run failed. View the logs →

  ^{｜ Rerun failed job ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using GPT Sol ｜ 𝕏}

[pullfrog]

Run failed. View the logs →

  ^{｜ Rerun failed job ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using GPT Sol ｜ 𝕏}

[thomasluizon]

@pullfrog review

[pullfrog]

Important

The API-first rollout leaves a supported paid feature advertised but no longer honored; the blocking billing finding is inline.

Reviewed changes at c56677a9 cover the complete color-scheme collapse and its API, domain, agent, export, and test surfaces.

• Collapsed behavior: all six historical write values remain accepted, but non-null writes store orange and profile reads always return orange.
• Preserved contracts: the nullable string DTO shape remains intact, legacy raw values remain in data exports, and no migration rewrites stored rows.
• Agent and test updates: the obsolete agent snapshot field was removed, tool and catalog descriptions were aligned, and domain, round-trip, export, profile, and catalog coverage was expanded.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using GPT Sol ｜ 𝕏}

[thomasluizon]

Thomas decided on 2026-09-25: ticket #367 is redesign work, so this PR targets orbit-api redesign/main, not main. The colour-scheme collapse ships with the redesign, never ahead of it. The next run retargets or rebuilds this PR on redesign/main.

[thomasluizon]

@pullfrog review

[pullfrog]

Important

The latest merge disables Dependency Review and SonarCloud because both workflow files now contain duplicate top-level YAML keys.

Reviewed changes since the prior Pullfrog review at c56677a9 covered the two branch synchronization commits and the resulting full PR diff.

• Synchronized branches: Merged current main and redesign/main into the feature branch without changing the color-scheme runtime or wire-contract behavior.
• Reconciled generated state: Carried the updated architecture artifacts and test dependencies from the synchronized branches.
• Duplicated workflow configuration: The redesign merge left two workflow files with repeated top-level concurrency mappings; the blocking consequence is documented inline.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using GPT Sol ｜ 𝕏}

[pullfrog]

Important

No additional findings were found, but the existing paid-feature contract and workflow-loading threads remain unresolved, so this head is not ready for approval.

Reviewed changes covered the complete current diff at f82ec430, including the color-scheme collapse, its tests and agent surfaces, the cross-repo client contract, and the branch synchronization changes.

• Color-scheme behavior: All historical keys remain accepted, non-null writes and profile reads resolve to the granted accent, legacy stored values remain truthful in exports, and the wire shape stays unchanged.
• Agent and test surfaces: The obsolete snapshot field is removed, tool and catalog text reflects the collapse, and domain, round-trip, profile, export, and catalog coverage exercises the changed behavior.
• Branch synchronization: The latest merges add duplicate top-level workflow mappings; that high-severity issue was submitted by another Pullfrog run on this same head while this review was in progress, so it is not duplicated inline here.
• Cross-repo contract: orbit-ui-mobile redesign/main retains the nullable string contract and maps all six historical keys to the granted accent; installed clients still preserve the paid picker behavior covered by the earlier open thread.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using GPT Sol ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes since the prior Pullfrog review at f82ec430 covered the workflow repair in b083c0a7.

• Restored workflow loading — Removed the duplicate top-level concurrency mappings from Dependency Review and SonarCloud, leaving one mapping in each workflow while retaining their redesign/main pull-request triggers.
• Preserved PR behavior — Left the color-scheme runtime, append-only wire contracts, generated architecture artifacts, and test surface unchanged.

  ^{｜ View workflow run ｜ Using GPT Sol ｜ 𝕏}

[thomasluizon]

@pullfrog review

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[pullfrog]

✅ No new issues found.

Reviewed changes at b792e03d cover the complete current diff, the color-scheme contract across both repositories, and the latest merge-forward.

• Collapsed behavior: All six historical keys remain accepted, non-null writes and profile reads resolve to the granted accent, and null writes still clear the stored preference.
• Preserved contracts and data: The nullable wire shape and endpoint remain unchanged, while exports continue to report legacy stored values without a migration rewriting existing rows.
• Aligned agent surfaces: The obsolete snapshot field is removed, and chat, MCP, capability, and catalog text now describes the collapsed behavior consistently.
• Cross-repo compatibility: orbit-ui-mobile redesign/main preserves the string contract, maps every historical key to the granted accent, and removes the color-scheme preference surface.
• Verification: The focused domain, application, and infrastructure test sets passed with 123 tests and no failures; the worktree remained clean after OpenAPI generation.

  ^{｜ View workflow run ｜ Using GPT Sol ｜ 𝕏}