The probe took its include directory from $ServerRoot/MetasequoiaImeEngine/contracts, which is where the engine sat when it was a submodule of Server. It is a submodule of the repository now, so the path does not move with -ServerRoot. A missing include directory is not a configure error, so this surfaced minutes later as C1083 on a header nobody had moved; the script now checks and says so before building.
The local packaging rehearsals had the same stale assumption, looking for MetasequoiaImeTsf, MetasequoiaImeServer and MetasequoiaImeUiHtml beside the installer. Worse, they skipped the build when a neighbour was absent, which in this layout means every build is skipped and whatever binaries are lying around get packaged into an installer you then run on your own machine. The three components are directories of this repository, so a missing one is now a hard failure, and Prepare-PackageFiles.ps1 is passed the directory names it needs.
Both were missed because the sweep that moved the submodules read its own output through head, so a truncated list looked like a complete one. Re-checked by resolving every relative path literal in every tracked file with no filtering.
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.
The lock pins immutable commits, but nothing checked that anybody merged them. Today it pins server 40d85a4 and engine 9a4b0c6, both of which exist only on architecture/product-contracts branches, and a release built from this commit would have shipped and attested to a Server that never reached main. The release job's existing provenance check covers only the TSF commit being released, not the inputs the lock names.
verify-published compares each locked commit against its own repository's default branch and accepts only behind or identical, the two states that mean it is an ancestor. ahead and diverged both mean the commit sits on something nobody merged.
It runs in the release path and deliberately not in product-ci.yml. A pull request legitimately locks branch commits while one change lands across several repositories at once, which is exactly the situation this branch is in; enforcing reachability in pull request CI would deadlock the landing it exists to protect. At release time the judgement inverts, because an input that never reached its default branch is an input nobody reviewed.
Evan Hu