the signals and their derived score are provisional and subject to change.
validate manually before sharing.
dae74478168d0ab3e0b0ff3a7cb1aa52920f0523none
# CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
## Build & Test Commands
```bash
# Build entire workspace
cargo build
# Run all tests (requires env vars for integration tests)
cargo test
# Run tests for a specific crate
cargo test -p filen-sdk-rs
cargo test -p filen-mobile-native-cache
# Run a specific test
cargo test -p filen-sdk-rs --test file_tests test_name
# Unit tests only (no network, no test account needed)
cargo test --lib
#---
name: mobile-build
description: How to build this Rust code into the filen-ts mobile apps for on-device testing — how each of the two consumption paths is wired (Drive cache via git submodule, @filen/sdk-rs via published npm package), ubrn Android/iOS commands, the debug-vs-release performance trap, and the stale-xcframework and prebuild gotchas. Read before building, running, or profiling the mobile app against local SDK changes.
---
# Building filen-rs into the mobile apps
## The two consumption p---
name: codebase-search
description: >
Use before writing or reviewing code, calling any function/method you have not read, using any
type you have not seen defined, adding an import, or implementing a pattern that may already
exist. Also when asked how something works, or whether something exists. Default posture:
search first, then write. Never invent paths, names, or APIs.
---
# Codebase Search — Search First, Then Write
## When to Search
Search before proceeding if:
- You're abou---
name: live-docs
description: >
Use before writing or reviewing code that calls into any external library, API, or
framework. Training data goes stale — identify the exact installed version from the
project's manifest/lockfile (Cargo.toml, package.json, pyproject.toml, go.mod,
Package.swift, ...), then fetch docs for that version before writing.
---
# Live Documentation Lookup
Training data goes stale. APIs change, options get renamed, majors break things. Look the
API up **before** w---
name: tdd
description: >
Test-driven development in any language: write the test that specifies the behavior,
then the code. Use when implementing a feature, fixing a bug (failing test first),
refactoring, or adding coverage. Covers cargo test, Jest/Vitest/bun:test, pytest,
go test, swift test, and E2E (Playwright, Maestro). Trigger when the user mentions
tests, coverage, TDD, spec, red/green, a flaky test, or an E2E flow.
---
# Test-Driven Development
Tests are not optional. Every---
name: filen-api-behavior
description: Server-side Filen API semantics that are NOT visible from this repo's code — same-name upload versioning, case-insensitive name-hash dedup, and which uuid the dir-link endpoints are keyed by. Read before writing or reviewing upload, rename, collision-handling, or public-link code.
---
# Filen API behaviour (server-side semantics)
These are facts about the **server**, confirmed against the backend or the official
`filen-sdk-ts`. They cannot be derived by reading ---
name: fold-fixups
description: Fold fix-up commits on an UNPUSHED branch into the commits they correct, so the history a reviewer sees has each change done right the first time — how to decide what folds where (blame-based plan, split mixed fixes, keep pre-existing-bug fixes standalone), how to do it non-interactively in this harness (amend! commits + --autosquash with editor env vars), how the target's message gets rewritten, and the end-tree identity check that proves nothing was lost. Use after a r---
name: types-serde-conventions
description: Conventions for adding or changing types in filen-types / filen-sdk-rs — the permissive_u64 serde helpers and their two gotchas, and the #[js_type] macro arguments including the externally-managed-serde pattern. Read before adding a field to an API type, adding a new API type, or touching a type that carries #[js_type].
---
# Type & serde conventions
## `permissive_u64` — every deserialized `u64`
`filen-types/src/serde/number.rs` defines `permissive_u64`---
name: security
description: >
Use when writing or reviewing code that handles: file uploads or filesystem paths,
credentials/API keys/secrets, cryptography, user input, authentication or
authorisation, outbound requests to user-supplied URLs, or dependency changes.
Checks for: injection, path traversal, hardcoded secrets, insecure crypto, missing
ownership checks, SSRF, mass assignment, and information leakage. Also flags
security issues in adjacent code.
---
# Security — Writ---
name: verify-changes
description: >
Run the project's own format / lint / typecheck / test commands after a code change and
before calling it done. Detects the toolchain from the repo's manifest — Cargo.toml
(cargo fmt --check, clippy, cargo test --lib), package.json (lint / tsc / test scripts),
pyproject.toml (ruff, pytest), go.mod, Package.swift — runs what exists scoped to the
files that changed, and fixes failures at the root cause instead of suppressing them.
Use after e---
name: triage-test-run
description: Diagnose a red GitHub Actions run of this repo — the nightly `Tests` matrix (six native legs, test-wasm, test-2fa) or `Continuous Integration` — from a run id / URL or "why was last night red". Fetches every leg's log, parses the failures, groups them by root cause, investigates + live-confirms + adversarially refutes each cause with a fixed Sonnet/Opus/Fable workflow, and delivers a table (issue, kind, failures caused, legs, recurrence, confirmed?, suggested fix, ---
name: code-style
description: >
Match an existing project's code style before writing or editing source files, in any
language (Rust, TypeScript, Python, Swift, Go). Use when about to add, edit, or create a
source file in a repo you did not write. Loads the cached style index at
.claude/code-style-index.json; if it is missing, detects the project's formatter config
from its build manifest, reads real source files, and writes the index. Not needed for
prose, config-only edits, or ---
name: commit-work
description: >
Create high-quality git commits: review and stage only the intended changes, split them
into logical commits, and write clear Conventional Commit messages. Use when asked to
commit, stage changes, write a commit message, or split work into several commits.
---
# Commit Work
Goal: commits that are easy to review and safe to ship — only intended changes, logically scoped, with messages that say what changed and why.
## Inputs to ask for (if missing)
- Sing---
name: no-hallucination
description: >
ALWAYS active. Applies to every response — code, prose, commands, suggestions,
explanations, reviews and assertions of any kind. Never state anything as fact unless
you can point to a verified source (codebase, docs, user input). When uncertain,
verify first or say "I'm not sure". Resolution order:
(1) search the codebase, (2) read the project's manifest and config,
(3) fetch docs, (4) ask the user.
---
# No Hallucination — Verified Factnone