The product README was under windows/ after the move, but it was never a component readme: it is the download page, the feature guide and the contribution guide for the whole product, so it goes back to the root and windows/ gets a real component readme.
AGENTS.md at the root now carries the repository map, the component boundaries that used to be cross-repository rules, and the release process, since the scripts that process drives live at the root. The component files keep what is genuinely theirs and say which paths they are relative to. References that named sibling repositories now name sibling directories, and the lock documentation records that Server, the pages, the GUI framework and the installer are no longer inputs to pin.
The product lock existed because five repositories had to be pinned to reproduce one product. Four of them are directories now, so a commit of this repository already pins them and there is nothing left for the lock to say about them. What it still records is what the product consumes from outside: the engine submodule, the helpcodes and the dictionary release.
CI gains a job per component instead of a reusable workflow that checked out locked commits and rebuilt them. The release workflow no longer stages five sibling checkouts under historical names and no longer carries a second sparse checkout for its own scripts; Prepare-PackageFiles.ps1 already took the source directory names as parameters, so it is told the new ones, plus where the product-wide notice now lives.
Two checks the removed cross-repository pins used to provide are replaced in kind: the pages are verified against the engine submodule's web contract in CI rather than by locking UiHtml and Engine together, and the engine bump triage that Server carried moves here and now also says so when a bump leaves the lock behind.
Windows, Server and UiHtml each carried their own gitlink to MSIME-Engine, all three pinned to the same commit, and Server carried a gitlink to MSIME-UI that is now the ui/ component. Git only reads the root .gitmodules, so the nested ones had to go regardless.
The engine and the two third-party dependencies now live once at vendor/MetasequoiaImeEngine, vendor/opencc and vendor/cpp-pinyin. Server reaches them through MSIME_VENDOR_DIR and builds ui/ as an out-of-tree subdirectory; the Windows tip's relative contract includes gained the extra level; the ui-html contract sync and the Server env/table generators follow the engine to its new location.
sciter/ held two HTML files and a .gitkeep for a rendering backend that no longer exists. Nothing selects them: appearance.ui_backend in MSIME-Server accepts only "d2d" and "webview2", no source file in any repository of the organisation mentions Sciter, and Prepare-PackageFiles.ps1 never packaged the directory, so the files did not reach an installation either.
The README described the directory as the old backend's resources while calling WebView2 the current default, which reads as though Sciter were still selectable. It is not, so the row goes with the files.
The history keeps the markup if the old candidate window layout is ever wanted as a reference.
The releases link in the About page and both the href and the visible link
text in the Feedback page still pointed at MetasequoiaImeTsf, which only
resolves through GitHub's rename redirect. These are links users click from
inside the settings window, and the visible text showed the old repository
name back to them.
The TSF frontend has been MSIME-Windows for a while; every other cross-repo
reference in the organization already uses that name.
This repository had no CI and no dependabot, while the settings page under
webview2/settings/ime-settings is a Vite and TypeScript project that the Windows release workflow
builds. Until now pnpm build only ever ran while cutting a release, so a break here surfaced at
the worst possible moment.
pnpm-workspace.yaml declared only onlyBuiltDependencies. pnpm 10 honours that key, which is why
releases worked, but pnpm 11 reads allowBuilds instead: it refuses to run esbuild's postinstall,
exits 1, and rewrites the file with a "set this to true or false" placeholder. So pnpm install
--frozen-lockfile fails outright for anyone on a current pnpm. Declaring allowBuilds alongside the
existing key satisfies both, verified against 10.34.5 and 11.25.0.
packageManager pins the pnpm version so a local checkout and CI agree through corepack.
dependabot now covers npm as well as actions. The template used across the other repositories only
declares github-actions and gitsubmodule, so the settings page dependencies were unwatched: they
sit one to two majors behind, with typescript at 5.9 against 7.0 and vite at 7.2 against 8.2.
Those bumps are left to dependabot rather than done here.
The README described only the symlink debug trick, through one developer's absolute paths, and
never mentioned that the settings page has to be built at all.
Generate settings candidate previews from [candidate.dark]/[candidate.light]
and document skin.toml. Candidate HTML remains for the settings mockup;
the runtime window is no longer WebView2.
Evan Hu