mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-11-07 06:19:43 -10:00
qqqys
f2f10e7b39
* feat(settings): turn cross-session messaging on by default The switch has been opt-in since the feature landed, which was the right posture while the pieces that make a reachable session safe were still arriving one pull request at a time: authenticated inboxes, receipts and held-message expiry, review-class parity with tighten-only repository settings, trusted controller tokens, admission control, the registry contract, daemon-managed sessions and the SDK peer endpoint. With all of that in place, off by default no longer protects anything. It only means a voice front-end joining through the SDK cannot see a session whose user never found the setting, and two sessions in one repository cannot tell each other a build finished. Flip the schema default to true. Merged settings carry only what some scope actually wrote, so the schema default never reached the readers of this key: every one of them saw `undefined` and compared it to `true`. The four readers now ask one helper, which answers on for `true` and for an unset key, and off for `false` and for anything it does not recognize — a value the reader cannot interpret must not open a socket. The workspace tighten-only ranking follows: unset now ranks with `true`, so a repository's `false` is a tightening and is kept, and a workspace `true` repeats the default and is dropped without a warning. The words change with the default. `/peers` on a session with no inbox distinguishes "turned off in settings" from "the inbox could not start" instead of telling the user to enable a setting that is already on. On a platform without an inbox transport, the startup failure line is shown only to a user who turned the switch on by hand; a bind that failed where it should have worked is still reported to everyone, because that session is unreachable and this line is the only place its user learns it. The controller-token hint, the send_message error, the settings reference, the SDK guides and the messaging section of the commands page now say what turning the feature off looks like. Suites that stage a session through partial mocks turn the switch off in their settings, or complete the config mock where registration now runs; the daemon-session and interactive-startup suites are where unset-means-on is exercised. Part of #10925 * test(cli): turn messaging off in suites that stage startup or ACP sessions through partial mocks Two suites the default flip reaches that the first commit missed. The entry-point startup test counts exit-cleanup registrations, and with messaging on the inbox arms a third. The ACP worktree-restore suite loads sessions through an exhaustive core mock, and with messaging on each loaded session registers itself through calls that mock does not stage. Neither suite is about messaging, so both say off in their settings; the on-by-default path is exercised in startInteractiveUI.test and the daemon-session suite of acpAgent.test. * refactor(cli): name the opted-in-by-hand check next to the enabled helper The startup failure notice asks two questions three lines apart: whether messaging is on, which the shared helper answers and an unset key answers yes, and whether the user wrote `true` themselves, which decides whether an unsupported platform is worth mentioning. The second read the raw setting inline, next to a helper documented as the one place the first question is answered, and looked like a missed migration. Bind it to a name so the two questions read as two. * fix(cli): address review on the default-on switch: scope-aware notices, no futile rebinds, honest docs Review round one on the default flip. Thirteen suggestions, all taken. Two readers now ask a question merged settings cannot answer, so both move next to `isCrossSessionMessagingEnabled` in peerMessaging/enabled.ts: - Whether a person opted in. The startup notice for a platform with no inbox transport is said only to someone who wrote `true`; it read the merged value, which also carries an operator's system-defaults file, so a fleet default counted as a hand opt-in. It now reads the user scope, and the workspace scope when it is trusted and active. - Which scope turned messaging off. `/peers` told everyone their settings said `false` and to set it to true. Anything but `true` or unset reads as off, so it no longer states the value, and it names the scope with a remedy that works there: a workspace `false` outranks a user `true` (a workspace may only tighten), System overrides everything, and a user `true` does override system defaults. `/peers` on a platform with no inbox transport now says so as information. It was error-styled and repeated the failure's advice to disable a setting most of those users never enabled. An ACP process no longer retries the bind for every hosted session after `unsupported_platform`. That refusal holds for every candidate path, so the settled null is kept; every other cause still retries. The design doc, in both languages, names the two senders delivered without review that the default now reaches: a process the session starts, which inherits the child token, and a same-user process that claims the receiving session's review class, which nothing authenticates. It records why they are documented rather than gated. The setting's description, the settings reference and the VS Code schema carry the same clause, and the Windows paragraph says what changes there. `commands.md` no longer promises a warning for a workspace `true` that merely repeats the default. Tests pin what was unpinned: a daemon-hosted session with the key unset registers; one bind attempt under `unsupported_platform` and a retry under any other cause; the warning when a workspace `true` would reopen a switch the user turned off; the operator-default startup case; the scoped off messages. Negative assertions that stopped being able to fail are repointed, and stale "off by default" test names and comments are gone.