Imported from RaraAlu/Dali (AGENTS.md). Install upstream with npx skills add RaraAlu/Dali. Copyright stays with the author.

Repository Guidelines

Project Structure & Module Organization

This repository is a Rust 2024 desktop application built with eframe/egui.

• src/main.rs: current application entry point and GUI prototype.
• Cargo.toml: package metadata and direct dependencies.
• Cargo.lock: locked dependency graph; commit it for reproducible application builds.
• DEVELOPMENT_PLAN.md: product scope, architecture direction, milestones, and accepted decisions.
• target/: generated build output; never commit it.

Keep UI state in app.rs, domain types in model.rs, and network code in focused modules such as discovery/, proxy/, and ssh/. Put integration tests in tests/ and unit tests beside their implementation.

Build, Test, and Development Commands

• cargo run: build and launch the desktop GUI.
• cargo check: quickly validate types without producing a final binary.
• cargo test: run all unit, integration, and documentation tests.
• cargo fmt --check: verify standard Rust formatting.
• cargo clippy --all-targets --all-features -- -D warnings: run strict static analysis.

Coding Style & Naming Conventions

Use four-space indentation and let rustfmt determine layout. Follow Rust naming conventions: snake_case for modules, functions, and variables; PascalCase for structs, enums, and traits; SCREAMING_SNAKE_CASE for constants.

Keep egui rendering lightweight. Network work must run outside the GUI thread with timeouts and cancellation. Prefer typed configuration and structured errors.

For every egui/eframe change, use the egui API index as the primary reference for API usage, types, and methods. Use egui.rs and its official examples as the primary reference for implementation and layout patterns. Confirm examples against the repository's pinned crate version before coding. Prefer official widgets, layouts, styling, viewport commands, drag/resize behavior, and input handling. Add custom behavior only when the official API does not cover the requirement, and record the reason in DEVELOPMENT_PLAN.md.

Testing Guidelines

Name tests after observable behavior, for example rejects_port_above_65535. Cover state transitions, validation, cancellation, and cleanup. Network tests should use local fixtures or mocks. Add a regression test for each bug fix where practical.

Commit & Pull Request Guidelines

Treat every completed, coherent task as a commit boundary. Before ending work:

1. Inspect git status and the relevant diff.
2. Run applicable formatting, tests, and Clippy checks.
3. Stage only files belonging to that task.
4. Commit immediately, then verify the working tree.

Do not leave completed changes uncommitted unless the user explicitly requests it. Never include generated output, secrets, or unrelated user changes. Split unrelated work into separate commits.

Use Chinese Conventional-style subjects such as 功能(proxy): 增加手动端口校验. For non-trivial commits, add 变更内容 and 验证 sections.

Pull requests should explain changes, list verification commands, link the plan item, and include screenshots for GUI changes. Highlight security and compatibility risks.

Security & Configuration

Only scan authorized networks. Never log passwords, keys, subscription URLs, or tokens. Validate proxy ports and bind temporary tunnels to loopback. Keep DEVELOPMENT_PLAN.md synchronized with requirement or architecture changes.