AI Flow

@@ -12,7 +12,7 @@ Read the target's latest PR comments, reviews, linked issues and development ins 4. Read EVERY hunk of `review.diff`, especially deleted code, module/verb registration, braces and cfg(test) boundaries. The lexical inventory cannot prove scope. Format changed Rust code consistently, without a repository-wide formatting rewrite. 5. For Rust, run a normal production `cargo check --workspace --bins` with required features, then the combined workspace tests. This catches a production function accidentally nested under cfg(test), which tests alone can miss. Preserve previous capability tests and explicitly inspect their call sites. Run native acceptance for IPC transaction timing, Undo, revision, rendering and DRC claims. Record anything not tested on hardware. 6. Re-read HEAD immediately before submission. If it moved, apply the focused patch onto the new immutable base, resolve conflicts semantically, and repeat the combined checks. Do not just change the recorded base hash.-7. Prefer a wiki branch PR: `branch create <repo> <branch> --from <hash>`, `repo push <repo> --branch <branch> --files <paths> -m <message>`, inspect `branch compare <repo> --head <branch>`, then `pr create <repo> --from <branch> --title ... --body-file ...`. File-set PRs serialize whole-file replacements; they are not an adequate substitute for a reviewed contextual branch diff.+7. Prefer a wiki branch PR: `branch create <repo> <branch> --from <hash>`, `repo push <repo> --branch <branch> --files <paths> -m <message>`, inspect `branch compare <repo> --head <branch>`, then `pr create <repo> --from <branch> --title ... --body-file ...`. If `branch create` is refused because your account has no manage rights on the repository (every user outside the owning org), open a file-set PR instead: `pr create <repo> --files <paths> --title ... --body-file ...` from a fresh clone of the head you recorded, and give that base hash in the body. A file-set PR carries whole files, so keep the file list to what you changed, and the maintainer reviews it against the head at merge. Never attach a patch to an issue in place of a PR: a PR is what a maintainer can review and merge. 8. Read the actual PR diff after submission. Check that it matches the reviewed paths and hunks. If a race or unexpected diff appears, keep it draft or close it and repair it. A live-head check is not an atomic server lock; branch ancestry preserves the base for the maintainer's merge. 9. PR body: exact base hash, scope, dependencies, preserved capabilities, commands/results, native acceptance status, remaining limitations. Owner review, merge, publication, installation and live verification are distinct states. Do not self-merge another bridge owner's change or replace a shared runtime.