​

Security And Reliability

​

Reliability At A Glance

• CI-parity build checks are expected to stay green at every commit.
• Architecture boundaries are treated as machine-checkable guardrails, not only taste.
• Kernel authorization and audit behavior should fail closed instead of silently degrading.
• Shipped assistant and channel flows should surface persistence and provider failures rather than hiding them.

​

Reliability Covers

• build invariants that should stay green at every commit
• runtime and architecture guardrails
• kernel and channel safety expectations that are part of the public operating contract
• the machine-checkable architecture and verification commands contributors are expected to use

​

Security At A Glance

• High-risk capability use should pass through capability, policy, and audit gates.
• Operator-facing security posture should be inspectable through loong doctor security.
• Outbound web and channel HTTP behavior should keep SSRF-style trust boundaries explicit.
• Execution surfaces should expose a shared security-tier vocabulary instead of inventing one policy story per lane.

​

Security Covers

• disclosure expectations
• runtime safety boundaries
• public-facing hardening notes that matter for contributors and evaluators
• current operator-facing audit and security-posture surfaces

​

Typical Public Questions This Page Should Answer

​

Typical Commands

cargo fmt --all -- --check
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace
cargo test --workspace --all-features
loong doctor security

​

Use These References When

• you want to understand what the project treats as non-negotiable
• you are evaluating whether a change weakens an existing public contract
• you need to distinguish stable expectations from internal planning notes

​

Repository Source Material

• Reliability
• Security
• Security Policy