Skip to main content

verifying-openlogi-changes

Plans regression proofs and runs OpenLogi verification based on the diff, affected packages, host OS, and work stage. Use when planning a bug fix, after repository changes, when reviewing test coverage, or before an authorized commit or push.

跳到安装

来源信息

仓库
AprilNEA/OpenLogi
最近来源活动
2026年9月18日 19:18
检测到的 SKILL.md 语言
英语
星标
21,783
分支
712

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
verifying-openlogi-changes
description
Plans regression proofs and runs OpenLogi verification based on the diff, affected packages, host OS, and work stage. Use when planning a bug fix, after repository changes, when reviewing test coverage, or before an authorized commit or push.
# Verify OpenLogi Changes Use the smallest check that can disprove the change, then apply the required final gate. ## Classify before running checks 1. Inspect `git status --short`, staged and unstaged diffs, and new files. For branch work, include all changes against the intended base, not only the last commit. Preserve unrelated work. Check whether Rust-bearing rebases or conflict resolution occurred since the last full gate. 2. Read the root [iteration policy](../../../AGENTS.md#verification-while-iterating-fast-path) and each changed area's scoped rules. For a push, also read the [local gate](../../../.agents/rules/ci.md#local-gate-hard-stop-before-push--scale-it-to-the-affected-graph). This skill applies those policies; it does not make the pre-push gate mandatory for every local edit. 3. Classify the diff by what it controls, not only by extension: - Prose, skill text, or images alone are non-Rust; do not compile Rust for them. - Rust source **or build/validation inputs** are Rust-bearing. A `Cargo.toml`, lockfile, toolchain, or CI change is not a docs-only change. 4. State the proof before editing: affected behavior, likely wrong implementation, and an input or interaction where the expected result differs from that mistake. ## Reproduce regressions before fixing them - For a bug fix, run the smallest reproducer before changing production code. Drive normal actions or the existing injected backend, not corrupt private state. Confirm failure on the reported path, not a compile error or unrelated setup failure. - Use the test layer's existing barriers, events, or logical time. Do not add sleeps or retries to hide an ordering bug. - Record the violated invariant, its owner, reproduction command, and observed failure. If reproduction is unavailable, state the missing evidence and what a substitute test proves. Do not claim the original bug is verified fixed. - After the fix, run the same reproducer and a nearby non-failing case that would catch an overbroad change. Report both before and after results. ## Iterate, then stabilize - While code moves, run one focused test or package check. For Rust, use `cargo test -p <package> <test-filter>` or `cargo check -p <package>`. Inspect the test count; a filter that matches zero tests is not evidence. - Once stable, run formatting, relevant tests, and Clippy for each changed Rust package as specified in the root policy. Check affected consumers for shared API changes. Do not run full-workspace checks after every edit. - For non-Rust changes, check the actual files: spelling, whitespace, links, manifests, or executable behavior. Select shell/Nix/packaging checks from the [CI map](../../../.agents/rules/ci.md#if-you-changed-x-run-y), not Rust by habit. ## Select the pre-push gate only when pushing 1. Use the local gate's non-Rust checks or Rust-bearing tier selection. 2. For Rust-bearing work, apply the local gate's full-tier triggers first. Do not select the affected-package tier merely because few files changed. 3. Otherwise derive the affected set from the final dependency graph: ```sh cargo tree --workspace --target all --invert <changed-package> ``` Repeat for every changed package. Take the union of workspace packages, including transitive consumers. Run the local gate's affected-package tier for that entire set, not just the edited crate directories. 4. Use the exact commands and compiler flags in the local gate. Keep Git hooks enabled. After a failure, fix the cause with a focused check, then rerun the applicable tier on the final tree. Do not push a known-red tree. ## Add checks for the affected boundary Consult the [CI job map](../../../.agents/rules/ci.md) for exact commands: `cargo xtask ci --list` lists jobs; `cargo xtask ci --dry-run` prints planned commands but does not verify them. Run required named jobs rather than assuming the host gate reproduces all CI. | Changed boundary | Additional evidence | | --- | --- | | IPC or serialized wire types | [IPC rules](../../../crates/openlogi-ipc/AGENTS.md), version discipline, fixed-byte `wire_format` tests; roundtrips alone are insufficient | | Platform `cfg` code | [Cross-platform rules](../../../.agents/rules/cross-platform.md), target checks or the required manual audit; host-green is not cross-platform-green | | UI or localization | [UI workflow](../testing-openlogi-ui/SKILL.md), [i18n rules](../../../.agents/rules/i18n.md), rendered/interaction evidence and catalog checks | | Fixtures | [Fixture workflow](../contributing-device-fixtures/SKILL.md), strict offline verification and independent semantic review | | Dependencies, portable crates, MSRV, docs, packaging | The corresponding extra jobs in the CI map, including wasm/rustdoc when applicable | Report each command's decisive result, the tested host, and the scope it proves. List failed, skipped, and unavailable checks separately. State real-hardware verification explicitly. Do not count a skip, dry run, or manual audit as an executed test. Do not commit, push, create a PR, rerun remote workflows, or release merely because this skill was loaded; follow the task's authorization.
在 GitHub 查看