1 Commits

Include renames

Author	SHA1	Message	Date
TryWorldandh4rK8s	efd501ec74	agent: add Reasonix Studio with separate Executor and Plan models (#427) ... * feat(agent): add Reasonix Studio 2.x integration * agent: select Reasonix planner independently from executor * agent: restore Reasonix when its credential file was initially absent * agent: preserve Reasonix planner choices and model controls Keep configured and saved native planner references selectable, and retain full model picker behavior and role labels. Exercise native planner restoration and both browser layouts. Separate temporary CLI first-launch work from version and intentional timeout assertions. * test(gui): follow the current Reasonix connection flow * test(gui): open connected Reasonix details before checking roles * agentenv: isolate Reasonix configuration in test sandboxes * gui: restore Reasonix roles without disconnecting the other * gui: Reasonix's role labels read in every language, and its confirm names them The review found four things on the Reasonix roles' strings. "executor" and "planner" are field labels like any other, so t() translates them; they had no i18n entry in any language, so the zh, ja and de windows showed the English key. They now read 执行模型/规划模型, 実行モデル/計画モデル and Executor-Modell/Planner-Modell, beside model/effort/thinking in each block. The confirm said "neither Executor nor Plan" — names that appear nowhere in the UI — and its zh text said "Executor 和 Plan", while the fields are labelled executor and planner. It now names the labels, and each language names its own translation of them (zh 执行模型和规划模型, ja 実行モデルも計画モデル, de vom Executor- bzw. Planner-Modell). Both new strings had a zh entry and no ja or de entry, which is what turned gui-ja and gui-de red: every zh key needs its ja and de with the same placeholders. "restore the previous {field} selection" also started at column 0 in i18n.js; it is indented with the lines around it now. reasonix-roles.test.cjs asserts the rendered label, so its zh expectations name 执行模型/规划模型; the en ones stay as they were, the en label being the key. Its en assertions on the confirm's first sentence are unchanged, and the reworded second sentence is not asserted. Verified on this head: gui-ja passes 3/3 and gui-de 3/3 (every zh string has its ja and de, same placeholders and tags); reasonix-roles.test.cjs passes 8/8 in Chromium and WebKit, en and zh, window (1000px) and panel (440px); go vet ./... and the four builds pass. The rest of internal/gui/tests was run and compared against a clean main worktree at e0bf3e61: the same assertions fail on both, and none of them is about i18n or Reasonix (see the PR comment). * edit: a TOML value is written the way TOML reads it, preserving or not setTOMLTop spelled every value with strconv.Quote. Go's escapes are not TOML's: a control byte came out as \x01, and TOML defines no \x escape, so a preserving edit wrote a config.toml that no parser reads — an agent's own value could not be written at all. Worse, it only failed at writeTOML, after the edit was already decided. The preserving path and the path that adds a key now both use tomlLiteral, as SetTOMLKey already did, so both write the same encoding. tomlString spells a basic string from the TOML spec (\b \t \n \f \r \" \\, \uXXXX for the other control bytes and DEL, everything else as it is, non-ASCII included). A byte that is not valid UTF-8 has no TOML escape, so it is left as it is and writeTOML refuses the file, rather than the value being quietly replaced by U+FFFD. TestTOMLPreservingKeepsAValueTOMLCanParse parses the file back with the TOML parser and compares the value, and TestTOMLPreservingAndPlainAgreeOnEncoding puts the same value through both paths and compares the bytes. TestSetTOMLKeepsCRLF's "top = \"9\"" is "top = 9" now: an int is a TOML integer, the same value SetTOMLKey writes for it, and no caller but that test passes anything but a string here. Verified on this head: go test ./internal/edit/ passes whole; the two new tests and TestSetTOMLKeepsCRLF pass under -race -count=10; go vet ./... and the four builds pass. TestTOMLBigFileParsesInLinearTime fails under -race -count=10 on this head and on a clean main at e0bf3e61 alike (a 1s budget against ~1.2s under the detector); it passes without -race. --------- Co-authored-by: h4rK8s <63350517+h4rk8s@users.noreply.github.com>	2026-10-06 16:14:35 +08:00