Adopt the phase 2 Rust baseline (toolchain, rustfmt, lints)

[leynos]

Summary

Brings evert into line with Waves 2 and 3 of Operation Parabellum, the
estate's phase 2 Rust baseline remediation. evert is a greenfield
skeleton, so the change is entirely configuration: the canonical
rustfmt and Clippy configuration, the full canonical lint set in
Cargo.toml, a toolchain component list that now includes
rust-analyzer alongside the repository's existing components, and
the replacement of the unconditional Cranelift dev-profile override
with the estate's opt-in dev-fast build. One genuine lint violation
surfaced once the canonical lints were applied and was fixed rather
than deferred. This branch is self-contained: it carries its own copy
of the opt-in dev-fast configuration rather than depending on the
separate Wave 1 pull request landing first. All Cranelift/mold
build-tooling detail now lives exclusively in the developers' guide;
the users' guide only points there, per a later sponsor ruling on the
correct audience boundary between the two documents. A further sponsor
decision makes dev-fast the standard local development path rather
than an opt-in side path: make build, make test, make lint, and
make typecheck now pass --config tools/dev-fast/config.toml to
every cargo invocation they make, guarded by a new contract test.

Review walkthrough

• Cargo.toml —
  the [lints.clippy], [lints.rust], and [lints.rustdoc] tables now
  carry every entry from the canonical lint sets (adding
  disallowed_methods, missing_assert_message, unknown_lints,
  renamed_and_removed_lints, unsafe_code, and the five missing
  rustdoc lints). evert has no [workspace] table, so the tables
  stay at crate level per the brief's placement rule.
• .rustfmt.toml —
  replaced verbatim with the canonical rustfmt configuration (it was
  already byte-identical, so this was a no-op copy at the time). A
  later commit re-synced the header comment after canon itself was
  corrected; see Notes.
• clippy.toml —
  replaced with the canonical configuration, which adds the
  disallowed-methods environment-injection mandate the repository
  did not previously enforce.
• rust-toolchain.toml —
  kept the existing nightly-2026-05-28 pin and added rust-analyzer
  to the component list. The TC-002 baseline rule requires the list to
  include rustfmt, clippy, and rust-analyzer, not match
  exactly, so the repository's existing llvm-tools-preview and
  rustc-codegen-cranelift-preview components stay in place — an
  earlier version of this branch dropped them in error; that was
  corrected before this pull request left draft (see Notes).
• .cargo/config.toml —
  removed the [unstable] codegen-backend = true and
  [profile.dev] codegen-backend = "cranelift" stanzas, which had
  applied the Cranelift backend to every dev-profile build
  unconditionally.
• tools/dev-fast/config.toml —
  new. The estate's opt-in dev-fast fragment (Cranelift plus mold),
  copied byte-identical from the separate Wave 1 pull request so the
  two merge cleanly whichever lands first. A later commit refreshed
  its two comments (a stale "copy this fragment" instruction, and a
  corrected description of Cargo's rustflags-merging semantics) to
  match an updated canon source, still byte-identical. See Notes.
• Makefile —
  gains the dev-build/dev-test targets that apply
  tools/dev-fast/config.toml explicitly via cargo --config, also
  copied byte-identical from Wave 1.
• AGENTS.md —
  gains the matching "Fast development builds" section, likewise
  copied byte-identical from Wave 1.
• docs/developers-guide.md —
  corrected to say development builds use the standard LLVM backend by
  default, with Cranelift-plus-mold described as the opt-in
  make dev-build/make dev-test path (nightly toolchain required;
  never applied to release, coverage, or verification builds). The
  mold-linker sentences about .cargo/config.toml, which remain
  true, are kept as-is. This is now the only place in the documentation
  set that discusses Cranelift or mold; see Notes.
• docs/users-guide.md —
  the users' guide no longer mentions Cranelift, mold, dev-fast, or
  codegen backends at all; every such sentence was replaced with a
  pointer to the developers' guide. Its Makefile-targets list keeps
  bare make dev-build/make dev-test entries with no mechanism
  explanation, likewise pointing at the developers' guide. See
  Notes.
• docs/repository-layout.md —
  drops the stale "code-generation settings" claim from the
  .cargo/config.toml bullet, and documents the new
  tools/dev-fast/config.toml file in both the tree diagram and the
  path-responsibilities list.
• typos.local.toml
  and
  typos.toml —
  add exemptions so mold (the linker's name) is not corrected to
  mould in the phrasings the new prose above uses repeatedly, and
  (separately) exempt inline code spans from the spelling gate
  entirely. A later commit replaced an initial blanket mold
  word-correction with five pattern-scoped phrase exemptions, since
  the blanket form disabled genuine "mould" misspelling detection
  everywhere, not just for the linker references it was meant to
  cover; see Notes. typos.toml is regenerated from the
  exemptions each time.
• tests/stub.rs —
  the generated stub test read CARGO_MANIFEST_DIR via
  std::env::var_os, which the newly-adopted disallowed_methods
  lint denies. Switched to the option_env! macro, which resolves the
  same value at compile time and needs no injected environment reader.
• docs/developers-guide.md —
  new "Lint baseline" section documenting the previously-undocumented
  maintainer convention behind the Cargo.toml lint tables: they live
  under [lints.clippy]/[lints.rust]/[lints.rustdoc] at crate
  level (no workspace inheritance), Cargo.toml stays authoritative
  rather than the doc duplicating the list, genuine deferrals use
  #[expect(clippy::<lint>, reason = "...")] rather than allow so a
  fixed site's unfulfilled expectation warns, clippy.toml carries the
  thresholds and the disallowed_methods environment-injection
  mandate, and the pinned nightly supplies the rustfmt, clippy, and
  rust-analyzer components the baseline depends on.
• Makefile —
  the build, test, lint, and typecheck targets now pass
  --config "$(DEV_FAST_CONFIG)" to every cargo invocation they make,
  so plain make build/test/lint/typecheck already use the
  dev-fast profile; release, coverage, and audit are unaffected.
  build resolves through the target/%/$(TARGET) pattern rule it
  depends on, conditionally excluding --config for the release
  case that rule also serves. DEV_FAST_CONFIG is declared a second
  time near the top of the file so the standard targets, which sit
  above the appended Wave 1 block, can see it. A later commit changed
  the Wave 1 block itself, replacing its hard-coded cargo with
  $(CARGO) in both recipes so the injectable variable every other
  target already honours reaches these two as well; see Notes for
  both this and the earlier byte-identity note.
• AGENTS.md —
  a new "dev-fast is the standard development path" section, appended
  after (not editing) the existing Wave 1 "Fast development builds"
  section, tells an agent or human that direct cargo build/test/
  clippy/check/doc calls for development work need the same
  --config flag the Makefile targets now pass, and that mixing
  direct-cargo and make invocations without it thrashes the
  incremental build cache.
• tests/makefile_contract.rs —
  reads the Makefile textually and asserts the build, test,
  lint, and typecheck recipes reference --config and the
  dev-fast fragment, that coverage's recipe does not, and that
  tools/dev-fast/config.toml exists — so an over-eager future edit
  fails this repository's own suite before the estate-wide audit
  (concordat's forthcoming DF-004 rule) would catch it centrally. File
  access goes through cap_std::fs_utf8::Dir and camino::Utf8Path
  rather than std::fs, per this repository's capability-filesystem
  convention (also enforced here by Whitaker's
  no_std_fs_operations lint). A later commit hardened the standard-
  target assertion to check each $(CARGO)-invoking recipe line
  individually rather than the block as a whole, and added
  substitution coverage for dev-build/dev-test via
  make --dry-run <target> CARGO=probe-cargo; see Notes.
• Cargo.toml —
  adds rstest, cap-std (fs_utf8 feature), and camino as
  dev-dependencies for the new contract test.
• .github/workflows/ci.yml —
  comment-only fix. The comment above whitaker-installer --cranelift
  claimed this project "builds with the Cranelift debug backend"
  without saying how, which read as though .cargo/config.toml still
  supplied it by default; it does not, since an earlier commit on this
  branch removed that default. Reworded to say Cranelift now only
  applies through the opt-in tools/dev-fast/config.toml fragment
  that the build/test/lint/typecheck targets pass explicitly,
  and that this Lint step's own Whitaker invocation does not pass
  --config, so it lints under the default LLVM backend regardless.
  See Notes for the verification behind this being a comment-only
  fix rather than a wiring bug.
• .github/workflows/release.yml —
  comment-only fix, found while verifying the ci.yml comment above.
  Two comments (near the "Install cross" and "Build release binary"
  steps) still described .cargo/config.toml as setting a Cranelift
  codegen backend and claimed rust-toolchain.toml "specifies nightly
  with Cranelift for development". Reworded to say
  .cargo/config.toml contains the Linux mold linker configuration
  only; Cranelift now lives solely in the opt-in
  tools/dev-fast/config.toml fragment, which release builds never
  read. See Notes.

Validation

• cargo fmt --all under the pinned nightly — no changes; the tree
  was already formatted to the canonical style.
• cargo clippy --all-targets --all-features — clean after the
  tests/stub.rs fix, and re-verified clean after restoring the
  toolchain components.
• cargo test --workspace (unit, integration, and doc tests) — all
  pass.
• make check-fmt — passes.
• make lint (cargo doc --no-deps, cargo clippy, Whitaker Dylint
  suite) — passes.
• make test (cargo nextest run, cargo test --doc) — passes.
• make audit (cargo audit) — passes, no advisories.
• make build, make test, make lint, make typecheck run for
  real under the wired Makefile (not just cargo directly), forcing a
  rebuild each time (make -B build) to confirm the actual recipe
  text executes: all four pass, and make -n dry-runs confirm
  --config "tools/dev-fast/config.toml" appears in each one's
  expanded command line while make -n release and make -n coverage
  confirm neither picks it up.
• The wiring is real, not just textual: cargo --config "tools/dev-fast/config.toml" build -v --bin evert (forcing a
  rebuild) shows -Z codegen-backend=cranelift in the actual rustc
  invocation, while a plain cargo build -v --bin evert (also forced)
  shows zero matches for codegen-backend=cranelift — the fast
  backend only ever applies when the fragment is in play.
• Regression coverage for tests/makefile_contract.rs sanity-checked
  by hand: temporarily stripped --config from the typecheck
  recipe, confirmed cargo test --test makefile_contract failed with
  a clear message (standard_targets_use_dev_fast::case_4, "must pass
  --config to cargo..."), then restored the Makefile from git show HEAD:Makefile and re-confirmed all six tests pass again.
• markdownlint-cli2 '**/*.md' — 0 errors.
• nixie --no-sandbox — all Mermaid diagrams validated successfully.
• make spelling — passes. It failed on one pre-existing finding for
  most of this branch's history; see Notes for how it was cleared.
• make dev-build and make dev-test run for real under the pinned
  toolchain (not dry-run): both succeed, dev-test running all 9
  tests including the contract test's own 8 cases. cargo test --test makefile_contract also run directly: 8/8 pass, up from 6 before
  this round's hardening (the two new
  dev_fast_targets_honour_cargo_override substitution cases).
  make lint, make check-fmt, make typecheck, markdownlint-cli2,
  nixie, make spelling, and make audit all re-run clean after
  both commits in this round; see Notes.

Notes

• Toolchain components corrected before merge: the first version
  of this branch narrowed rust-toolchain.toml's component list to
  exactly rustfmt, clippy, and rust-analyzer, dropping the
  repository's pre-existing llvm-tools-preview and
  rustc-codegen-cranelift-preview. TC-002 only requires those three
  canonical components to be present, not an exact match, and the
  dropped components back this repository's own coverage and dev-fast
  tooling. A follow-up commit on this branch restored them; the
  component list now reads clippy, llvm-tools-preview,
  rust-analyzer, rustc-codegen-cranelift-preview, rustfmt.

• Self-contained dev-fast build, added after review: removing the
  Cranelift dev-profile default from .cargo/config.toml without a
  replacement would have left this branch, on its own, with no
  accelerated debug build and docs that still described the removed
  default. This branch now carries its own copy of
  tools/dev-fast/config.toml, the Makefile's dev-build/dev-test
  targets, and AGENTS.md's matching section — each verified
  byte-identical to the corresponding file on the separate Wave 1
  pull request's branch (parabellum-wave-1), so the two merge
  cleanly regardless of landing order and do not conflict.
  rustc-codegen-cranelift-preview (the compiler component that makes
  the Cranelift backend available) was never removed; only the
  .cargo/config.toml stanza that switched every dev-profile build to
  use it unconditionally was.

• No #[expect] sites were added. The one lint violation found
  (clippy::disallowed_methods in tests/stub.rs) had a direct fix
  (option_env! instead of std::env::var_os) rather than needing a
  deferral.

• make spelling now passes end-to-end, a pre-existing failure
  cleared by a later commit at the sponsor's request:
  docs/documentation-style-guide.md deliberately quotes color
  inside backticks as the US-spelling example the style guide itself
  instructs contributors to keep verbatim, and the typos checker read
  it as prose needing correction to colour. Inline code spans quote
  identifiers literally and are not en-GB prose, so the fix is the
  estate's existing backtick-span exemption (precedented in netsuke's
  typos.local.toml) rather than an accepted-word entry for color
  repo-wide, which would have weakened the check everywhere instead of
  only inside code spans. Added "`[^`\\n]+`" to
  typos.local.toml's [patterns] ignore list and regenerated
  typos.toml through the repository's own generator so the committed
  and regenerated configs agree.
  docs/documentation-style-guide.md itself was not touched. The
  mold findings that this branch's new prose introduced, and the
  pre-existing mold findings in docs/developers-guide.md and
  docs/users-guide.md, were resolved at the time by a mold
  word-correction exemption; a later commit replaced that blanket form
  with the scoped exemptions described in Notes below, without
  reopening any of these findings.

• Component-retention clarified in the developers' guide, added
  after a second review pass: its Tooling section now names
  llvm-tools-preview and rustc-codegen-cranelift-preview as the
  pinned toolchain components the dev-fast path depends on, and states
  that tools/dev-fast/config.toml — not the toolchain pin by itself —
  is what controls the repository-local opt-in activation. This
  clarification originally also went into docs/users-guide.md; the
  audience-boundary ruling below removed it from there.

• Users' guide/developers' guide audience boundary, established by a
  later sponsor ruling that supersedes the component-retention note
  above where the two conflict: the users' guide must not mention
  Cranelift or mold at all, because linker internals and the opt-in
  accelerated build path are a developer concern, not a user concern.
  Every Cranelift/mold/dev-fast/codegen-backend sentence was removed
  from docs/users-guide.md (verified with a case-insensitive
  grep -ni "cranelift\|mold\|dev-fast\|codegen-backend" docs/users-guide.md, which now matches nothing) and replaced with
  pointers to the developers' guide. Nothing needed porting:
  docs/developers-guide.md's Tooling and Lint baseline sections
  already covered every fact the users' guide had stated, including
  the component-retention clarification above, so the removal is
  purely subtractive. The typos.local.toml exemptions for mold
  stay, because the developers' guide still uses the word.

• .rustfmt.toml's header comment corrected, added after a further
  review pass: the file originally carried canon's template
  instruction verbatim — "Copy this file to the repository root as
  .rustfmt.toml" — which reads as nonsense sitting at that very
  path. Canon's own source has since been corrected to describe the
  file in place rather than instruct a copy that has already happened;
  this branch's header comment now matches it exactly, with every key
  unchanged. .rustfmt.toml remains byte-identical to
  platform-standards/canon/lint/rust/rustfmt.toml.
  tools/dev-fast/config.toml was not touched by this fix and remains
  byte-identical to parabellum-wave-1.

• dev-fast is now the standard development path, a further sponsor
  decision, 2026-08-13, that supersedes earlier framing of dev-fast as
  purely opt-in: make build, make test, make lint, and
  make typecheck route every cargo invocation through
  --config tools/dev-fast/config.toml, so a plain make <target>
  already gets the fast profile — the separate make dev-build/
  make dev-test targets from Wave 1 still exist and behave the same
  as before, they are just no longer the only way to get the fast
  profile. release, coverage, and audit are explicitly excluded
  and keep the supported LLVM backend and platform linker; a new
  contract test (tests/makefile_contract.rs) guards both the
  inclusion and the exclusion so a future edit cannot silently drop
  either. CI needed no changes: ci.yml and act-validation.yml
  already reach build/test/lint through make targets (so they
  inherit the new wiring automatically, with no direct cargo
  invocation for a development build, test, lint, or typecheck run
  anywhere in this repository's own workflow files), and ci.yml and
  coverage-main.yml already install the mold linker on Linux
  runners — verified by reading both workflows, not assumed, since
  .cargo/config.toml already makes mold the default linker for
  every build in this repository, dev-fast or not.
  rust-toolchain.toml already pinned rustc-codegen-cranelift-preview
  (restored in an earlier commit on this branch), so no toolchain
  change was needed either. Recommended merge order is
  parabellum-wave-1 first, then parabellum-wave-2-3, though the
  Makefile/AGENTS.md hunks are kept disjoint from the Wave 1 blocks so
  either order merges cleanly.

• ci.yml's Whitaker/Cranelift comment corrected, verified sound
  rather than a wiring bug: checked whether this repository has the
  skyjoust-class bug where a Makefile's Whitaker recipe line is wired
  with --config even though Whitaker's dylint driver runs on its own
  pinned toolchain, separate from the project's. It does not:
  grep -n "WHITAKER" Makefile confirms the lint target's Whitaker
  line carries no --config flag (only the cargo doc/cargo clippy
  lines above it do), and the current PR head's CI run
  (leynos/evert build-test job, Lint step) compiled and finished
  cleanly, confirming the combination is sound on a clean runner. The
  --cranelift half of the original comment was accurate as written
  and is kept, expanded to say explicitly that Whitaker's own toolchain
  pin is separate from this project's; only the second half's
  implication about where Cranelift comes from was corrected.

• release.yml's Cranelift comments corrected too, added after
  they were flagged: while verifying the ci.yml comment, two
  stale comments were found in release.yml as well (around the
  "Install cross" and "Build release binary" steps), which still
  described .cargo/config.toml as setting a Cranelift codegen
  backend and claimed rust-toolchain.toml "specifies nightly with
  Cranelift for development". Neither is true any more: Cranelift now
  lives solely in the opt-in tools/dev-fast/config.toml fragment,
  which release builds never read, so there is nothing to isolate it
  from. Reworded both to say .cargo/config.toml contains the Linux
  mold linker configuration only. Comment-only: a diff restricted to
  added/removed lines confirms every changed line is a comment, no
  run:/env: values changed.

• tools/dev-fast/config.toml refreshed from canon: replaced two
  stale comments verbatim — a "Copy this fragment to
  tools/dev-fast/config.toml" instruction that reads as nonsense
  sitting at that exact path (the same class of staleness
  .rustfmt.toml had before an earlier commit on this branch fixed
  it), and a mis-statement of Cargo's rustflags semantics claiming
  Cargo picks a single rustflags source rather than merging them.
  Canon now correctly says Cargo joins the rustflags of every matching
  [target.*] entry, and the joined target rustflags take precedence
  over [build].rustflags rather than merging with it. Every key is
  unchanged; diff against
  platform-standards/canon/build/rust/dev-fast.toml confirms
  byte-identity.

• typos.local.toml's blanket mold exemption replaced with
  pattern-scoped ones: the earlier mold = "mold" entry under
  [words.corrections] disabled genuine "mold"-for-"mould" detection
  repository-wide, not just for the linker references it was meant to
  cover. Replaced with five phrase-scoped entries in [patterns]
ignore, alongside the existing backtick-span entry (final bytes,
  in typos.local.toml):

  [words.corrections]
  
  [patterns]
  ignore = [
    "`[^`\\n]+`",
    "-fuse-ld=mold",
    "mold linker",
    "Cranelift \\+ mold",
    "Cranelift and mold",
    "`mold`",
  ]

  Checked every "mold" occurrence in this repository's .md files
  (docs/repository-layout.md, docs/developers-guide.md,
  AGENTS.md) against the five patterns plus the backtick-span
  exemption; all are covered, so no sixth pattern was needed.
  Validated both directions after regenerating typos.toml: make spelling still passes end-to-end, and a scratch file (created
  outside the repository at /tmp/scratch-mold-check.md, never
  committed, deleted immediately after the check) containing "the
  bread had mold growing on it" is correctly flagged as `mold` should be `mould` by typos --config typos.toml against the
  regenerated configuration.

• Cross-application closing round: $(CARGO) in the dev-fast
  block, an Error-severity finding from a sibling repository's
  (statelet's) PR. The appended dev-build/dev-test recipes
  hard-coded cargo even though the Makefile already defines an
  injectable CARGO ?= cargo that every other target honours.
  Replaced cargo with $(CARGO) in both recipes; nothing else in
  the block changed. This changes the Wave 1 block's bytes, which the
  parabellum-wave-1 branch mirrors — final block bytes (from
  DEV_FAST_CONFIG through the last recipe line):

  # Opt-in accelerated debug builds (Cranelift + mold); requires a nightly
  # toolchain. See AGENTS.md and tools/dev-fast/config.toml.
  DEV_FAST_CONFIG ?= tools/dev-fast/config.toml
  
  .PHONY: dev-build dev-test
  dev-build: ## Build debug binaries with Cranelift and mold
  	$(CARGO) --config "$(DEV_FAST_CONFIG)" build
  
  dev-test: ## Run tests with Cranelift and mold
  	$(CARGO) --config "$(DEV_FAST_CONFIG)" test

  (Recipe lines are tabs.) Verified with make --dry-run dev-build CARGO=probe-cargo, which now emits probe-cargo --config "tools/dev-fast/config.toml" build.

• Cross-application closing round: contract test hardened to
  per-line assertions, an mpsc-log finding. The prior
  standard_targets_use_dev_fast checked the whole recipe block for a
  --config substring, which is a whole-block match: a target with
  several $(CARGO) lines (test's nextest-plus-doctest,
  lint's doc-plus-clippy) would still pass if only one of those
  lines carried the flag. Rewrote it to filter each block down to its
  $(CARGO)-invoking lines and assert --config plus the dev-fast
  reference on every line individually. Added the statelet-style
  substitution cases too: dev_fast_targets_honour_cargo_override
  runs make --dry-run dev-build|dev-test CARGO=probe-cargo via
  std::process::Command and asserts the emitted line contains
  probe-cargo, then --config, then a dev-fast reference, in that
  order — proving the fix above actually reaches the recipe, without
  needing the pinned nightly or mold installed.

  Mutation-tested by hand, then restored before committing: stripped
  --config from test's doc-test line only (leaving its nextest
  line intact) — standard_targets_use_dev_fast::case_2 failed,
  naming the test target and quoting the exact offending line;
  restored via cp from a pre-edit backup, diffed to confirm an exact
  match, re-ran to confirm all 8 tests passed again. Then hard-coded
  cargo back into dev-build only —
  dev_fast_targets_honour_cargo_override::case_1 failed while
  case_2 (dev-test, untouched) stayed green; restored and
  re-confirmed all 8 pass. make_dry_run returns Result rather than
  panicking internally, since Whitaker's no_unwrap_or_else_panic
  lint only tolerates .expect() in functions literally marked
  #[test]/#[rstest], matching the same convention the file's
  existing helpers already followed for no_std_fs_operations.

  make dev-build and make dev-test also run for real (not
  dry-run) under the pinned nightly-2026-05-28 toolchain in this
  environment: both succeed.

• Cargo.lock is untracked in this repository; that predates this
  change and was left as-is, since it is unrelated to the baseline
  being adopted here.

• No Concordat rule validation was run, per instruction; that happens
  centrally afterwards.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 11aedacf-06e3-4bb5-a5c6-d21c7b59c960

📥 Commits

Reviewing files that changed from the base of the PR and between 2884cf8 and d629fef.

📒 Files selected for processing (6)

• .cargo/config.toml
• .rustfmt.toml
• Cargo.toml
• clippy.toml
• rust-toolchain.toml
• tests/stub.rs

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• leynos/shared-actions (auto-detected)

💤 Files with no reviewable changes (1)

• .cargo/config.toml

---

Summary

Adopt the phase 2 Rust baseline for evert.

• Apply canonical Cargo lint, rustfmt, and Clippy configurations.
• Add rust-analyzer while retaining existing pinned toolchain components.
• Remove the unconditional Cranelift dev-profile override.
• Replace std::env::var_os with option_env! in tests/stub.rs.
• Pass formatting, Clippy, tests, documentation, audit, Markdown, Mermaid, and related checks.
• Note that make spelling still fails on pre-existing documentation misspellings.

Walkthrough

Remove the unstable Cranelift setting. Add stricter Rust, Clippy and rustdoc lint policies. Document rustfmt usage, add rust-analyzer, and replace a runtime environment lookup in the test stub.

Changes

Rust tooling and lint enforcement

Layer / File(s)	Summary
Configure lint and toolchain policy .cargo/config.toml, Cargo.toml, clippy.toml, .rustfmt.toml, rust-toolchain.toml	Remove the unstable Cranelift override. Configure disallowed environment methods, assertion-message checks, Rust and rustdoc lints. Document the canonical rustfmt configuration and add rust-analyzer to the nightly toolchain.
Replace runtime environment lookup tests/stub.rs	Use compile-time option_env! for CARGO_MANIFEST_DIR and document the lint rationale.

Possibly related PRs

• leynos/netsuke#505: Both enforce restricted environment access and update tests/stub.rs.
• leynos/agent-template-rust#79: Both apply the same environment-access lint policy and compile-time Cargo metadata handling.
• leynos/gauss#154: Both add overlapping Cargo, Clippy, toolchain and environment-access policies.

Poem

Rust guards rise, precise and bright,
Clippy watches day and night.
Environments stay safely still,
Docs align with every lint rule.
Analyzer joins the nightly crew.

---

Caution

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

• Ignore

❌ Failed checks (1 error, 1 warning, 3 inconclusive)

Check name	Status	Explanation	Resolution
Testing (Overall)	❌ Error	Add substantive tests: the diff changes lint and build behaviour, but the only Rust test remains a disposable stub that checks only CARGO_MANIFEST_DIR.	Add focused tests that fail when the canonical lint tables, disallowed-method rules, toolchain components, or Cranelift configuration are removed or misconfigured.
User-Facing Documentation	⚠️ Warning	The PR removes the root Cranelift debug override, but docs/users-guide.md still states that development builds use Cranelift; the user-facing build behaviour is therefore undocumented and misstated.	Update docs/users-guide.md to describe the new debug-build backend behaviour and remove the obsolete Cranelift claim. Synchronise docs/developers-guide.md if it carries the same claim.
Developer Documentation	❓ Inconclusive	Investigation is still required; the pull request changes tooling and lint requirements, but documentation coverage and the applicable base diff are not yet verified.	Inspect the developer guide, design documents, roadmap, and execplan against the pull-request diff.
Testing (Unit And Behavioural)	❓ Inconclusive	The diff shows only configuration and a disposable stub test, but the check does not define whether build-configuration changes require end-to-end coverage.	Clarify whether Cargo/toolchain configuration changes require dedicated behavioural or end-to-end tests.
Testing (Compile-Time / Ui)	❓ Inconclusive	I am still checking whether this PR introduces compile-time behaviour and whether an equivalent test already exists.	Inspect the changed Rust code and test infrastructure before deciding whether the required compile-time test is missing.

✅ Passed checks (15 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Module-Level Documentation	✅ Passed	Accept: all three Rust modules have module-level //! documentation; the PR adds no module without a purpose or component relationship description.
Testing (Property / Proof)	✅ Passed	Pass: the PR changes configuration and one compile-time environment check; it introduces no invariant over input ranges, states, orderings, transitions, or proof assumptions.
Unit Architecture	✅ Passed	The PR changes configuration and one test assertion only; it adds no query, command, fallible operation, dependency, or side-effect path.
Domain Architecture	✅ Passed	The diff changes only build, lint, formatting, toolchain configuration, and a test stub; no domain model, adapter, command, repository, transport, or persistence logic changed.
Observability	✅ Passed	Pass the check: the diff changes build, lint, formatting, toolchain, and stub-test configuration only; no production operational behaviour or new failure mode requires observability.
Security And Privacy	✅ Passed	The diff only changes Rust lint, formatting, toolchain, and build configuration; the test replaces a runtime environment read with compile-time option_env!, with no secrets, privilege changes, or...
Performance And Resource Use	✅ Passed	The diff changes configuration and one test assertion only; it adds no loops, collections, hot-path I/O, blocking work, or allocation, and replaces runtime environment access with compile-time `opt...
Concurrency And State	✅ Passed	Pass this check: the diff changes only configuration and one isolated test; it adds no shared mutable state, async work, locks, tasks, channels, or ordering logic.
Architectural Complexity And Maintainability	✅ Passed	Pass this check: the diff adds only repository configuration and a direct option_env! test fix; it adds no abstractions, dependencies, layers, registries, or lifecycle mechanisms.
Rust Compiler Lint Integrity	✅ Passed	The current tree shows no broad unused-code suppressions or clone-heavy Rust changes in the visible source files.
Title check	✅ Passed	The title accurately summarises adoption of the phase 2 Rust baseline through toolchain, rustfmt, and lint configuration changes.
Description check	✅ Passed	The description clearly explains the baseline configuration changes, related fixes, documentation updates, and validation results.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch parabellum-wave-2-3

---

_{Comment @coderabbitai help to get the list of available commands.}

[sourcery-ai]

Reviewer's Guide

This PR aligns the evert crate with the estate’s phase‑2 Rust baseline by updating lint configuration, clippy and rustfmt settings, toolchain components, and removing a non‑canonical Cranelift dev override, plus fixing the one real lint violation uncovered in tests.

Sequence diagram for the updated test stub environment resolution under disallowed_methods

sequenceDiagram
  actor Developer
  participant Cargo
  participant Clippy
  participant TestStub

  Developer->>Cargo: cargo clippy --all-targets --all-features
  Cargo->>Clippy: run_disallowed_methods_lint

  alt [before phase2_baseline]
    Clippy->>TestStub: analyze_use_of_std_env_var_os
    TestStub-->>Clippy: std::env::var_os("CARGO_MANIFEST_DIR")
    Clippy-->>Developer: diagnostic "inject an environment reader"
  else [after phase2_baseline]
    Developer->>Cargo: cargo test --workspace
    Cargo->>TestStub: execute_stub_test
    TestStub->>TestStub: option_env!("CARGO_MANIFEST_DIR")
    TestStub-->>Cargo: uses_compile_time_manifest_dir
  end

Loading

File-Level Changes

Change	Details	Files
Adopt canonical clippy configuration and enforce environment-injection via disallowed methods.	Retitle and comment clippy configuration as the estate’s canonical baseline with CodeScene-aligned thresholds. Add a disallowed-methods list covering std::env read/write APIs with explanatory reason strings. Document the expectation that sanctioned sites use #[expect(clippy::disallowed_methods, reason = "..")] instead of allow.	clippy.toml
Expand Cargo.toml lint tables to the full canonical Rust, Clippy, and Rustdoc lint sets.	Add disallowed_methods and missing_assert_message as deny-level Clippy lints in [lints.clippy]. Add unknown_lints, renamed_and_removed_lints, and unsafe_code = "forbid" to [lints.rust]. Add missing Rustdoc lints such as broken_intra_doc_links, bare_urls, and others to [lints.rustdoc]. Keep lint tables at crate level because there is no workspace table.	Cargo.toml
Align rustfmt configuration and toolchain components with the canonical baseline.	Replace .rustfmt.toml contents with the documented canonical rustfmt config, keeping unstable_features = true and related options. Update rust-toolchain.toml to keep the pinned nightly channel but narrow components to rustfmt, clippy, and rust-analyzer, removing llvm-tools_preview and rustc-codegen-cranelift-preview.	.rustfmt.toml rust-toolchain.toml
Remove the non-canonical Cranelift dev profile override from the repository root.	Delete the [unstable] codegen-backend = true and [profile.dev] codegen-backend = "cranelift" stanzas from .cargo/config.toml. Leave only the x86_64-unknown-linux-gnu target section configuring clang and mold linker flags, deferring any dev-fast opt-in to a future PR.	.cargo/config.toml
Fix the single lint violation revealed by the new baseline in the stub test.	Replace std::env::var_os("CARGO_MANIFEST_DIR") with option_env!("CARGO_MANIFEST_DIR") in the stub test to avoid clippy::disallowed_methods. Add a brief comment explaining the compile-time resolution and how it satisfies the environment-injection mandate.	tests/stub.rs

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Sorry @leynos, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d629fef5d6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[leynos]

@coderabbitai re:

User-Facing Documentation ⚠️ Warning The PR removes the root Cranelift debug override, but docs/users-guide.md still states that development builds use Cranelift; the user-facing build behaviour is therefore undocumented and misstated. Update docs/users-guide.md to describe the new debug-build backend behaviour and remove the obsolete Cranelift claim. Synchronise docs/developers-guide.md if it carries the same claim.

Developer focused behaviour does not belong in the user's guide.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@leynos Keep developer-focused build configuration out of docs/users-guide.md. The prior finding incorrectly classified this as user-facing behaviour.

Update docs/developers-guide.md only if it contains an obsolete Cranelift debug-build claim.

(ᵕ—ᴗ—)

---

🧠 Learnings used

Learnt from: CR
Repo: leynos/mxd PR: 0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2026-05-28T18:18:44.161Z
Learning: Applies to docs/users-guide.md : Exclude maintainer-only concerns from the user's guide (e.g., internal layering debates, future refactor plans, enforcement tooling) unless they directly affect users

---

Learnt from: CR
Repo: leynos/agentland PR: 0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2026-04-25T14:25:10.060Z
Learning: Applies to docs/users-guide.md : Exclude maintainer-only concerns from the user's guide such as internal layering debates, future refactor plans, or enforcement tooling unless they directly affect users

---

Learnt from: CR
Repo: leynos/stilyagi PR: 0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2026-06-04T21:48:49.731Z
Learning: Applies to docs/users-guide.md : Exclude maintainer-only concerns from the user's guide such as internal layering debates, future refactor plans, or enforcement tooling unless they directly affect users

---

Learnt from: CR
Repo: leynos/corbusier PR: 0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2026-06-15T07:11:34.645Z
Learning: Applies to docs/users-guide.md : Exclude maintainer-only concerns from the user's guide such as internal layering debates, future refactor plans, or enforcement tooling unless they directly affect users

---

Learnt from: CR
Repo: leynos/falcon-correlate PR: 0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2026-05-31T20:23:47.154Z
Learning: Applies to docs/users-guide.md : Exclude maintainer-only concerns from the user's guide such as internal layering debates, future refactor plans, or enforcement tooling unless they directly affect users

---

Learnt from: CR
Repo: leynos/wildside PR: 0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2026-06-06T00:18:38.023Z
Learning: Applies to docs/users-guide.md : In the user's guide, exclude maintainer-only concerns such as internal layering debates, future refactor plans, or enforcement tooling unless they directly affect users

---

Learnt from: CR
Repo: leynos/vk PR: 0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2026-06-21T15:21:02.653Z
Learning: Applies to docs/users-guide.md : In the user's guide, exclude maintainer-only concerns such as internal layering debates, future refactor plans, or enforcement tooling unless they directly affect users

---

Learnt from: CR
Repo: leynos/novel-ralph-skill PR: 0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2026-06-21T19:02:12.135Z
Learning: Applies to docs/users-guide.md : In the user's guide, exclude maintainer-only concerns such as internal layering debates, future refactor plans, or enforcement tooling unless they directly affect users

---

Learnt from: CR
Repo: leynos/spycatcher-harness PR: 0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2026-05-29T00:02:06.443Z
Learning: Applies to docs/users-guide.md : In the user's guide, exclude maintainer-only concerns such as internal layering debates, future refactor plans, or enforcement tooling unless they directly affect users

---

Learnt from: CR
Repo: leynos/actix-v2a PR: 0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2026-06-05T17:44:22.909Z
Learning: Applies to docs/users-guide.md : Exclude maintainer-only concerns from the user's guide (internal layering debates, future refactor plans, enforcement tooling) unless they directly affect users

---

Learnt from: CR
Repo: leynos/visual-storytelling-skills PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2026-05-05T12:34:41.375Z
Learning: Applies to docs/users-guide.md : New or changed user-facing functionality or behaviour must be clearly documented in the user's guide (`docs/users-guide.md`).

---

Learnt from: CR
Repo: leynos/python-skill PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2026-05-29T00:16:46.690Z
Learning: Applies to docs/users-guide.md : New or changed user-facing functionality or behaviour must be clearly documented in the user's guide (`docs/users-guide.md`).

---

Learnt from: CR
Repo: leynos/memoryd PR: 0
File: coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt:0-0
Timestamp: 2026-06-01T12:42:56.747Z
Learning: Applies to docs/users-guide.md : New or changed user-facing functionality or behaviour must be clearly documented in the user's guide (`docs/users-guide.md`).

_{You are interacting with an AI system.}

[codescene-access]

No quality gates enabled for this code.