Current DMG moved Project Task Sort comparator owner

[joshyorko]

Summary

The current DMG moved the project task creation-time comparator into a different shared webview chunk. When project-task-sort is enabled, the descriptor misses the new owner and candidate acceptance correctly rejects the Linux build.

Current upstream input

• App version: 26.707.62119
• DMG SHA-256: c243c94f8de6a51f5530ffe1f8d0c1588733d890ac692e34aaca06d95ba637ca
• Environment reproduced: Bluefin Linux, local upstream-release acceptance profile

Actual behavior

feature:project-task-sort:creation-time
status: skipped-optional
WARN: Could not find current project task creation timestamp insertion point - skipping project task sort feature patch

Because the feature is enabled, this is reported as enabled-feature-drift and the candidate is rejected instead of replacing the working app.

Local evidence packet

The current comparator is owned by:

app-initial~app-main~onboarding-page~projects-index-page~quick-chat-window-page~codex-micro~iqsnin5k-CcY42RXW.js

The old descriptor still targets the previous projects/remote-conversation chunk. The current owner also contains the persisted chatSortMode and projectSortMode normalization markers, which can provide the same fail-closed ownership check without retaining obsolete menu-string markers.

A focused current-DMG probe against the new owner after retargeting reports:

{"id":"project-task-sort","changed":true,"idempotent":true,"warnings":[]}

Focused Project Task Sort tests, the complete Linux feature test set, and the patch-runner suite pass with the current owner and markers.

Expected behavior

Retarget the descriptor to the current shared chunk and require the current sort-state markers before changing the comparator. Drift or mixed applied/unapplied shapes must remain byte-identical with one warning.

Scope

• Current DMG only; no previous chunk fallback.
• linux-features/project-task-sort/ only.
• No unrelated project UI or sort behavior changes.

[ilysenko]

@Yo-DDV I think the impact is very low.

[Yo-DDV]

@Yo-DDV I think the impact is very low.

@ilysenko This will require fine-tuning the governance and the label triage guide I proposed, so feel free to adjust it however you see fit, since the risk levels are pretty "subjective"

[ilysenko]

@Yo-DDV Thank you for taking care of this, but please don’t spend too much time on it. It will all be reworked later anyway. Codex will work either on my side locally all the time, or directly inside GitHub Actions. I’m currently figuring out how to pass it there. Thank you.

[Yo-DDV]

@ilysenko No worries. I changed #948 to impact: low, and I’ll stop there on my side.

When I opened the PR, I only meant it as a starting point for triage with labels. I did not expect it to be merged that quickly. The idea was to make issues and pull requests easier to scan during human reviews, while leaving the project’s governance as it is.

I hope some of it comes in handy when you revisit this. You know how you want Codex to fit into the project, so I’ll leave the rest with you. Thanks for the feedback. Happy to help whenever it makes sense.