agentleFS
loongclaw-ailoongclaw-ai/loongclaw/CLAUDE.md

loongclaw

CLAUDE.md640 starsChanged 7 months agoMITView on GitHub

This document is intentionally mirrored in CLAUDE.md and AGENTS.md. This file is the map — keep it short (~100 lines). Deeper repo-native context lives in docs/, while the public reader-facing docs surface lives in site/. The workspace currently has 13 crates across two connected families: Non-negotiable: no dependency cycles. See Core Beliefs. Current tracked deviations: none. loong-cli remains transitional; the shipped product entrypoint is still the loong binary in crates/daemon. Taskfile.yml provides optional convenience wrappers through the task CLI. If…

We split this CLAUDE.md into the rules it gives an agent

7 rules. About 0 are common, 2 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    If task is unavailable, run the underlying cargo and scripts/* commands directly.

    line 50
  2. Very specific:

    Test all features: ./scripts/cargo-local-toolchain.sh test --workspace --all-features

    line 57
  3. Very specific:

    All execution paths route through kernel capability/policy/audit.

    line 64
  4. Distinctive:

    Never commit credentials, tokens, or private endpoints.

    line 66
  5. Distinctive:

    Keep CLAUDE.md and AGENTS.md mirrored in the same change.

    line 67
  6. Very specific:

    Every released version must map to docs/releases/vX.Y.Z.md with process log and detail links.

    line 69
  7. Very specific:

    Use task verify when the task CLI is installed.

    line 88

≈ “Common” is an estimate: at least 1 in 5 of the 25,680 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
CLAUDE.md

Loong Agent Guide

This document is intentionally mirrored in CLAUDE.md and AGENTS.md.

This file is the map — keep it short (~100 lines). Deeper repo-native context lives in docs/, while the public reader-facing docs surface lives in site/.

1. Start Here

  • Repository Docs Map — audience routing for site/ vs docs/
  • Core Beliefs — kernel and engineering principles
  • Layered Kernel Design — layered model and boundary rules
  • Roadmap — stage-based milestones and acceptance criteria
  • Reliability — invariants and operating expectations
  • Code Standards — maintainability, test layout, and review checks
  • Product specs and implementation plans now live in eastreams/knowledge-base (see docs/README.md for routing)
  • Contributing Guide — contributor workflow and recipes

2. Architecture Contract

The workspace currently has 13 crates across two connected families:

additive spine
loong-core (leaf)
├── loong-plugin-sdk → loong-core
├── loong-runtime → loong-core
├── loong-app-protocol → loong-runtime
└── loong-cli → loong-app-protocol

governed runtime
contracts (leaf)
├── kernel → contracts, loong-plugin-sdk
├── protocol (independent leaf)
├── bridge-runtime → contracts, kernel, protocol
├── app → contracts, kernel
├── spec → contracts, kernel, protocol, bridge-runtime
├── bench → kernel, spec
└── daemon (`loong`) → app, loong-app-protocol, bench, bridge-runtime, contracts, kernel, protocol, spec

Non-negotiable: no dependency cycles. See Core Beliefs. Current tracked deviations: none. loong-cli remains transitional; the shipped product entrypoint is still the loong binary in crates/daemon.

3. Commands

Taskfile.yml provides optional convenience wrappers through the task CLI. If task is unavailable, run the underlying cargo and scripts/* commands directly.

  • Format check: ./scripts/cargo-local-toolchain.sh fmt --all -- --check
  • Strict lint: ./scripts/cargo-local-toolchain.sh clippy --workspace --all-targets --all-features -- -D warnings
  • Architecture check: ./scripts/check_architecture_boundaries.sh or task check:architecture
  • Convention check: task check:conventions (optional wrapper; requires Go + convention-engineering skill)
  • Test all features: ./scripts/cargo-local-toolchain.sh test --workspace --all-features
  • Canonical verify: task verify (optional wrapper around repo verification steps)
  • Extended verify: task verify:full (optional wrapper around the extended local gate)

4. Non-Negotiable Rules

  • Kernel contracts are backward-compatible. No breaking changes without documented decision.
  • All execution paths route through kernel capability/policy/audit. No shadow paths.
  • Strict lint and all-feature tests pass at every commit.
  • Never commit credentials, tokens, or private endpoints.
  • Keep CLAUDE.md and AGENTS.md mirrored in the same change.
  • Before every commit, run CI-parity checks. Any manual edit after fmt must be re-checked.
  • Every released version must map to docs/releases/vX.Y.Z.md with process log and detail links.
  • Local agent debug context for a release should be recorded in .docs/releases/vX.Y.Z-debug.md.
  • Public-repo issues, PRs, and public-doc wording should stay Loong-centric; keep detailed external project comparisons in eastreams/knowledge-base unless naming an external project is strictly necessary.

5. Verification Gates

CI enforces:

  • ./scripts/cargo-local-toolchain.sh fmt --all -- --check
  • ./scripts/cargo-local-toolchain.sh clippy --workspace --all-targets --all-features -- -D warnings
  • ./scripts/cargo-local-toolchain.sh test --workspace
  • ./scripts/cargo-local-toolchain.sh test --workspace --all-features

6. Pre-Commit Hook

cp scripts/pre-commit .git/hooks/pre-commit && chmod +x .git/hooks/pre-commit

Runs CI-parity cargo checks before each commit. Use task verify when the task CLI is installed. Otherwise run the underlying scripts/cargo-local-toolchain.sh and scripts/* verification commands directly.

7. Where to Look Next

NeedGo to
Architecture overview & crate DAGARCHITECTURE.md
Repository docs layeringdocs/README.md
Core principlesdocs/design-docs/core-beliefs.md
Layered architecturedocs/design-docs/layered-kernel-design.md
Design decisions, patterns & catalogdocs/design-docs/index.md
Harness engineeringdocs/design-docs/harness-engineering.md
Code standards, test layout & review checksdocs/design-docs/code-standards.md
Roadmapdocs/ROADMAP.md
Reliability invariantsdocs/RELIABILITY.md
Security model & gapsdocs/SECURITY.md
Product sense & principlesdocs/PRODUCT_SENSE.md
Release process conventionsdocs/releases/README.md
Product requirements / implementation planseastreams/knowledge-base
Repository support referencesdocs/references/README.md
Contributing recipesCONTRIBUTING.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.