chore: reuse shared Rust lint config from ai-shared

.agents/skills/update-deps/SKILL.md

@@ -63,6 +63,16 @@ If the request is vague, default to:
      over `cargo install cargo-outdated` (compiles from source,
      several minutes). As a fallback, use `cargo update --dry-run`
      plus targeted `cargo search` / `cargo info` checks
+   - flag prerelease-pinned deps separately: `bun outdated` and
+     `bun update` resolve the npm `latest` dist-tag, so a
+     dependency intentionally pinned to a prerelease channel
+     (`alpha`, `beta`, `rc`, `next`, `canary`, `dev`) never shows
+     up as outdated and never moves, even when newer prereleases
+     exist on its own channel. Grep the manifests and catalog for
+     prerelease specifiers, then compare each pin against its real
+     channel with `npm view <pkg> dist-tags`. A `bunfig.toml`
+     `minimumReleaseAgeExcludes` entry is a strong hint that a
+     package is deliberately tracked ahead of stable.
    - inspect open dependency PRs if the request is about triage
      rather than local edits
    - include GitHub Actions only when the request covers them
@@ -82,6 +92,9 @@ If the request is vague, default to:
    - minor: check new features and silent behavior changes
    - major: assume migration work
    - `0.x` minor: treat as potentially breaking
+   - prerelease (`beta`, `rc`, etc.): unstable channel; assume
+     breaking changes can land between any two prerelease builds,
+     so read the diff and validate even for a "small" bump
 
 5. **Read official upgrade sources**:
    - changelog or release notes
@@ -135,6 +148,10 @@ If the request is vague, default to:
    - for Cargo, prefer `cargo update -p <crate>` when the
      existing semver range already covers the new version; edit
      `Cargo.toml` only when bumping past the range
+   - prerelease-pinned deps are usually exact-pinned to a
+     non-`latest` dist-tag, so neither `bun update` nor `bun
+     update --latest` will move them; edit the pin by hand to the
+     target prerelease version and run `bun install`
    - after each batch passes validation, commit that batch before
      moving to the next one
 

.ai/manifest.json

@@ -11,5 +11,9 @@
       "linting"
     ],
     "local": ".ai/local/agents.md"
-  }
+  },
+  "sharedRootFiles": [
+    "rustfmt.toml",
+    "deny.toml"
+  ]
 }

.claude/commands/update-deps.md

@@ -58,6 +58,16 @@ If the request is vague, default to:
      over `cargo install cargo-outdated` (compiles from source,
      several minutes). As a fallback, use `cargo update --dry-run`
      plus targeted `cargo search` / `cargo info` checks
+   - flag prerelease-pinned deps separately: `bun outdated` and
+     `bun update` resolve the npm `latest` dist-tag, so a
+     dependency intentionally pinned to a prerelease channel
+     (`alpha`, `beta`, `rc`, `next`, `canary`, `dev`) never shows
+     up as outdated and never moves, even when newer prereleases
+     exist on its own channel. Grep the manifests and catalog for
+     prerelease specifiers, then compare each pin against its real
+     channel with `npm view <pkg> dist-tags`. A `bunfig.toml`
+     `minimumReleaseAgeExcludes` entry is a strong hint that a
+     package is deliberately tracked ahead of stable.
    - inspect open dependency PRs if the request is about triage
      rather than local edits
    - include GitHub Actions only when the request covers them
@@ -77,6 +87,9 @@ If the request is vague, default to:
    - minor: check new features and silent behavior changes
    - major: assume migration work
    - `0.x` minor: treat as potentially breaking
+   - prerelease (`beta`, `rc`, etc.): unstable channel; assume
+     breaking changes can land between any two prerelease builds,
+     so read the diff and validate even for a "small" bump
 
 5. **Read official upgrade sources**:
    - changelog or release notes
@@ -130,6 +143,10 @@ If the request is vague, default to:
    - for Cargo, prefer `cargo update -p <crate>` when the
      existing semver range already covers the new version; edit
      `Cargo.toml` only when bumping past the range
+   - prerelease-pinned deps are usually exact-pinned to a
+     non-`latest` dist-tag, so neither `bun update` nor `bun
+     update --latest` will move them; edit the pin by hand to the
+     target prerelease version and run `bun install`
    - after each batch passes validation, commit that batch before
      moving to the next one
 

.coderabbit.yaml

@@ -9,15 +9,15 @@ reviews:
   path_filters:
     - "!**/*.gen.ts"
     - "!**/*.generated.ts"
-    - "!**/drizzle/**/snapshot.json"
     # sync-ai: injected path filters
   auto_review:
     enabled: true
-    drafts: true
+    drafts: false
     auto_incremental_review: true
     auto_pause_after_reviewed_commits: 2
     ignore_title_keywords:
       - "wip"
+      - "draft"
     ignore_usernames:
       - "dependabot[bot]"
       - "github-actions[bot]"
@@ -58,5 +58,4 @@ knowledge_base:
       - "GEMINI.md"
       - "CONTRIBUTING.md"
       - "SECURITY.md"
-      - "**/.cursorrules"
       # sync-ai: injected code guideline file patterns

AGENTS.md

@@ -33,8 +33,10 @@ details unless they are already public in the repository.
 
 ## GitHub Interactions
 
-- When commenting on GitHub (PRs, issues), include "CC on behalf of @username" where
-  username is the GitHub handle of the person who requested the comment.
+- When commenting on GitHub (PRs, issues), append `CC on behalf of username`, where
+  `username` is the GitHub handle of the person who requested the comment. Keep the
+  handle as plain text: never prefix it with `@` or link the account, because the
+  attribution must not trigger a GitHub mention notification.
 - This repository (including PRs, commits, comments) is public. Never include
   marketing language, internal business context, pricing, competitive analysis, user
   identities, conversation specifics, or security architecture beyond what the diff
@@ -57,13 +59,22 @@ details unless they are already public in the repository.
   now is usually cheaper than migrating an `isX` flag later.
 - Conventional Commits: `feat:`, `chore:`, `fix:`, `docs:`
 - Rebase feature branches onto main (linear history)
+- Enable `git rerere` (`git config --global rerere.enabled true`, plus
+  `rerere.autoupdate true` to auto-stage what it resolves) so conflict
+  resolutions are recorded and auto-replayed across repeated or long rebases
 - Fail fast: validate at boundaries, return/throw early
 - Minimize brace nesting: invert conditions, early returns
 - Use named constants, not string literals for domain values
 - No direct `document.cookie` assignment
 - Avoid spread in loop accumulators (use `.push()`)
 - If you encounter a pre-existing bug or lint error while working on something else,
   fix it (separate commit)
+- Orchestrate across model tiers when your harness supports subagents and model
+  selection: delegate well-scoped, mechanical, or independently verifiable subtasks
+  (edits, searches, refactors, test runs) to a subagent on the cheapest model that
+  does them correctly; keep planning, cross-cutting design, security-sensitive work,
+  and final review on the primary model. If your tooling has no subagents or model
+  selection, ignore this.
 
 ## Design Principles
 
@@ -91,6 +102,13 @@ details unless they are already public in the repository.
 - When a type mismatch appears, trace it to the source (e.g., the handler or query
   that produces the wrong type) rather than casting at the consumer. Check git to
   verify you did not introduce the mismatch yourself before blaming the framework.
+- Never annotate or cast a value the compiler already infers, and never pass explicit
+  type arguments to inference-driven hooks (`useLoaderData<T>()`, `useQuery<T>()`, Eden
+  calls). Every annotation or explicit generic masks real errors and breaks the
+  inference chain; let inference flow and narrow at the boundary instead.
+- Validate object literals against a large union type (route, link, query options) with
+  `as const satisfies T`, not a `: T` annotation. `satisfies` checks the value without
+  widening it or paying the annotation's instantiation cost.
 - Use `.at(0)` when the element may not exist (signals possible absence). Use `[0]`
   only when existence is already established (length check, or a `// SAFETY:` comment).
 - Prefer arrow functions over function expressions
@@ -115,6 +133,9 @@ details unless they are already public in the repository.
 - If a return type is noisy enough to hurt readability, hoist it into a nearby alias
   such as `SomethingResult` and use it in the signature (e.g., `SomethingResult` or
   `Promise<SomethingResult>`). If the return type is simple, keep it inline.
+- Watch type-instantiation cost in hot generic paths (route trees, query options, Eden
+  surfaces): prefer narrowing (`satisfies`, route `from`, query `select`) over
+  annotation, and keep large unused types out of inferred return positions.
 
 ### Module Side Effects
 
@@ -182,6 +203,19 @@ details unless they are already public in the repository.
   organized by language/concept where relevant.
 - Public docs, logs, diagnostics, and comments should write `stella` lowercase.
 
+### Rust Extensible Rule Systems
+
+- For analyzers, detectors, linters, validators, and similar extensible rule
+  systems, prefer module-owned declarative rule specs. Co-locate the rule id,
+  diagnostic id, required inputs, dependencies, support resources, activation
+  predicate, execution hook, and tests with the rule implementation.
+- Keep central registries thin. They should preserve cross-module ordering and
+  expose iteration, not contain rule-specific branching, diagnostic mapping, or
+  activation logic.
+- Reach for macros or derives only when they remove repeated plumbing across
+  many rules. Humans should write domain behavior; generated code should handle
+  mechanical metadata wiring.
+
 ### Rust Module Side Effects
 
 - Avoid expensive module-level initialization. Prefer explicit prepare/build
@@ -206,6 +240,13 @@ details unless they are already public in the repository.
 - Use fixture parity tests when replacing an implementation in another language.
   The Rust core, TypeScript binding, and Python binding should produce the same
   structured result from the same fixtures.
+- Use `insta` snapshots for structured diagnostics, rule output, CLI output,
+  registry metadata, and other reviewable behavior diffs. Prefer YAML or JSON
+  snapshots over hand-written assertion lists when the important contract is the
+  full shape of the output.
+- Review snapshot changes deliberately with `cargo insta review` or
+  `cargo insta accept`; do not accept broad snapshot churn without explaining
+  the behavior change.
 - Benchmark behavior that is part of the product. Track cold start, warm run,
   artifact load, preparation, and execution separately.
 - Do not snapshot sensitive raw text unless the fixture is intentionally public

deny.toml

@@ -1,8 +1,11 @@
-# cargo-deny configuration. Run `cargo deny check`.
+# Portable stella cargo-deny configuration, distributed via ai-shared and pulled
+# into consumer repos through `.ai/manifest.json` "sharedRootFiles".
+# Run `cargo deny check`.
 #
 # Complements the PR `dependency-review` action (which only sees dependencies
 # added in a PR) with continuous full-tree checks: RustSec advisories, license
-# policy, dependency sources, and duplicate versions.
+# policy, dependency sources, and duplicate versions. The license allow-list
+# mirrors the org's dependency-review allow-list; keep the two in sync.
 
 [advisories]
 version = 2
@@ -12,8 +15,6 @@ ignore = []
 
 [licenses]
 version = 2
-# Mirror of the allow-list in .github/workflows/dependency-review.yml. Keep the
-# two lists in sync when adding a dependency with a new license.
 allow = [
   "MIT",
   "Apache-2.0",
@@ -34,20 +35,20 @@ allow = [
 ]
 confidence-threshold = 0.9
 # The allow-list mirrors dependency-review for parity; not every entry is
-# present in the current tree, so do not warn on the unused allowances.
+# present in a given tree, so do not warn on the unused allowances.
 unused-allowed-license = "allow"
 
 [bans]
 # Duplicate versions are a warning, matching clippy `multiple_crate_versions`.
 multiple-versions = "warn"
-# A wildcard version requirement is almost always a mistake in this workspace.
+# A wildcard version requirement is almost always a mistake.
 wildcards = "deny"
 allow-wildcard-paths = true
 
 [sources]
 unknown-registry = "deny"
 unknown-git = "deny"
 
-# The stella search-primitive crates are consumed as pinned git dependencies.
+# Allow pinned git dependencies from the stella organization.
 [sources.allow-org]
 github = ["stella"]

scripts/sync-ai-skills.sh

@@ -25,4 +25,8 @@ if [[ ! -f "$REPO_ROOT/.ai/shared/scripts/sync-ai-skills.sh" ]]; then
   exit 1
 fi
 
-bash "$REPO_ROOT/.ai/shared/scripts/sync-ai-skills.sh" "${args[@]}" "$REPO_ROOT"
+if [[ "${#args[@]}" -eq 0 ]]; then
+  bash "$REPO_ROOT/.ai/shared/scripts/sync-ai-skills.sh" "$REPO_ROOT"
+else
+  bash "$REPO_ROOT/.ai/shared/scripts/sync-ai-skills.sh" "${args[@]}" "$REPO_ROOT"
+fi