Add copilot instructions (#355)

Add some rudimentary copilot instructions.

Author: Hinton

.github/copilot-instructions.md

@@ -0,0 +1,122 @@
+This document provides explicit instructions for Copilot Agent to follow when working with this
+repository. It outlines the coding standards, project structure, and best practices to ensure
+high-quality contributions that align with the repository's goals and maintainability standards.
+
+## Repository Overview
+
+This is the Bitwarden SDK - a cross-platform library written in Rust that implements core business
+logic for the Bitwarden applications.
+
+The repository is organized as a **monorepo** containing multiple libraries (`crates`) located under
+`bitwarden_license` and `crates`. Some notable crates include:
+
+- **`bitwarden-core`** - Contains the underlying functionality of the SDK. This includes a Client
+  struct. Other crates in the SDK depend on bitwarden-core and provide extensions to the Client
+  struct to implement specific domains. **Avoid adding functionality to this crate and prefer to
+  implement it in feature crates.**
+- **`bitwarden-crypto`** - Cryptographic primitives and key management
+- **`bitwarden-api-*`** - Auto-generated API bindings (DO NOT edit manually)
+- **`bitwarden-uniffi`** - Mobile bindings wrapper
+- **`bitwarden-wasm-internal`** - WebAssembly bindings
+
+## Feature Flags
+
+The SDK uses the following rust feature flags for language bindings.
+
+- `uniffi` - Mobile bindings (Swift/Kotlin) via UniFFI
+- `wasm` - WebAssembly bindings with wasm-bindgen
+
+### Core Architecture
+
+The Client struct is the main entry point for the SDK and represents a single account instance. Any
+action that needs to be performed on the account is generally done through the Client struct. This
+allows the internals to be hidden from the consumer and provides a clear API.
+
+We can extend the Client struct using extension traits in feature crates. This allow the underlying
+implementation to be internal to the crate with only the public API exposed through the Client
+struct. Below is an example of a generator extension for the Client struct.
+
+Crates usually contains one or multiple `<domain>_client.rs` files which contains a Client struct
+that implements the core business logic for the domain.
+
+```rust
+/// Generator extension for the Client struct
+#[cfg_attr(feature = "wasm", wasm_bindgen)]
+pub struct GeneratorClient {
+    client: Client,
+}
+
+#[cfg_attr(feature = "wasm", wasm_bindgen)]
+impl GeneratorClient {
+    fn new(client: &'a Client) -> Self {
+        Self { client }
+    }
+
+    /// Generates a password based on the provided request.
+    pub fn password(&self, input: PasswordGeneratorRequest) -> Result<String, PasswordError> {
+        password(input)
+    }
+
+}
+
+// Extension which exposes `generator` method on the `Client` struct.
+pub trait GeneratorClientExt {
+    fn generator(self) -> GeneratorClient;
+}
+
+impl GeneratorClientExt for Client {
+    fn generator(self) -> GeneratorClient {
+        GeneratorClient::new(self)
+    }
+}
+```
+
+### Cross-Platform Bindings
+
+#### UniFFI
+
+UniFFI is used for mobile bindings (Swift/Kotlin). Crates must include the following in `lib.rs` to
+enable UniFFI support.
+
+```rust
+#[cfg(feature = "uniffi")]
+uniffi::setup_scaffolding!();
+```
+
+Structs and enums that are exposed through a domain client must be derive:
+
+- Structs: `#[cfg_attr(feature = "uniffi", derive(uniffi::Record))]`.
+- Enums: `#[cfg_attr(feature = "uniffi", derive(uniffi::Enum))]`.
+
+#### WASM
+
+WASM is used for web bindings. Structs and enums that are exposed through a domain client should
+derive tsify.
+
+```rust
+// Add import to top of file
+#[cfg(feature = "wasm")]
+use {tsify::Tsify, wasm_bindgen::prelude::*};
+
+#[derive(Serialize, Deserialize)]
+#[cfg_attr(feature = "wasm", derive(Tsify), tsify(into_wasm_abi, from_wasm_abi))]
+pub struct ExampleStruct {
+    // Fields here
+}
+```
+
+## Development Workflow
+
+### Building & Testing
+
+Use the following commands to build and test the SDK:
+
+- `cargo check --all-features --all-targets` to quickly verify code is valid.
+- `cargo test --workspace --all-features` to run tests
+
+### Formatting & Linting
+
+Before committing code, ensure it is formatted and linted:
+
+- `cargo +nightly fmt --workspace` for formatting
+- `cargo clippy --workspace` for linting

.github/instructions/cargo-style.instructions.md

@@ -0,0 +1,131 @@
+---
+applyTo: "**/Cargo.toml"
+---
+
+# Project coding standards for Cargo.toml
+
+## Workspace Dependency Management
+
+### External Dependencies
+
+When adding a new dependency to a `Cargo.toml`, you **MUST** scan all existing `Cargo.toml` files in
+the repository to ensure it is not already defined in another crate. If it is, you should add it to
+the workspace dependencies and remove it from the individual crate.
+
+```toml
+# ✅ DO: Define in root workspace
+[workspace.dependencies]
+serde = { version = ">=1.0, <2.0", features = ["derive"] }
+tokio = { version = "1.36.0", features = ["macros"] }
+```
+
+```toml
+# ❌ DON'T: Define different versions in individual crates
+[dependencies]
+serde = "1.0.150"  # Different version than workspace
+```
+
+### Internal Dependencies
+
+All internal crates must be listed in workspace dependencies with exact version matching:
+
+```toml
+[workspace.dependencies]
+bitwarden-core = { path = "crates/bitwarden-core", version = "=1.0.0" }
+bitwarden-crypto = { path = "crates/bitwarden-crypto", version = "=1.0.0" }
+```
+
+### Using Workspace Dependencies
+
+In individual crate `Cargo.toml` files, always reference workspace dependencies:
+
+```toml
+[dependencies]
+# ✅ DO: Use workspace dependencies
+serde = { workspace = true }
+bitwarden-crypto = { workspace = true }
+
+# ✅ OK: Add features to workspace dependency
+serde = { workspace = true, features = ["derive"] }
+
+# ❌ DON'T: Override workspace version
+serde = "1.0.200"
+```
+
+## Package Metadata
+
+### Required Workspace Inheritance
+
+All crates must inherit common metadata from workspace:
+
+```toml
+[package]
+name = "bitwarden-example"
+description = "Brief description of the crate's purpose"
+
+# Required workspace inheritance
+version.workspace = true
+authors.workspace = true
+edition.workspace = true
+rust-version.workspace = true
+readme.workspace = true
+homepage.workspace = true
+repository.workspace = true
+license-file.workspace = true
+keywords.workspace = true
+```
+
+## Feature Flags
+
+### Standard Feature Patterns
+
+Follow established feature flag patterns:
+
+- `uniffi` - Mobile bindings via UniFFI
+- `wasm` - WebAssembly support
+
+### Feature Flag Dependencies
+
+Use conditional dependencies with feature flags:
+
+```toml
+[features]
+uniffi = ["bitwarden-crypto/uniffi", "dep:uniffi"]
+wasm = ["dep:wasm-bindgen", "dep:tsify"]
+
+[dependencies]
+# Conditional dependencies
+uniffi = { workspace = true, optional = true }
+wasm-bindgen = { workspace = true, optional = true }
+```
+
+## Version Constraints
+
+Use compatible version ranges for external dependencies:
+
+```toml
+# ✅ DO: Allow patch updates
+serde = ">=1.0, <2.0"
+chrono = ">=0.4.26, <0.5"
+
+# ❌ DON'T: Pin to exact external versions unless necessary
+serde = "=1.0.150"
+```
+
+## Special Considerations
+
+### Patches
+
+Document any `[patch.crates-io]` entries with reasoning:
+
+```toml
+# Temporary fix for WASM compatibility issue
+# TODO: Remove when upstream releases fix
+[patch.crates-io]
+pkcs5 = { git = "https://github.com/bitwarden/rustcrypto-formats.git", rev = "abc123" }
+```
+
+### Profile Optimizations
+
+Development profiles are configured at workspace level - do not override in individual crates unless
+absolutely necessary.

.github/instructions/rust-style.instructions.md

@@ -0,0 +1,95 @@
+---
+applyTo: "**/*.rs"
+---
+
+# Project coding standards for Rust
+
+## Formatting and Linting
+
+- Use `cargo +nightly fmt` to format code
+- Use `cargo clippy` to lint code and catch common mistakes
+- All code must be formatted and linted before being committed
+
+## Error Handling
+
+### Avoid Panics
+
+- **Never use `unwrap()`** - `clippy` will forbid this
+- **Use `expect()` sparingly** - always provide a helpful message
+- **Prefer `?` operator** for error propagation
+
+```rust
+// ❌ DON'T: Use unwrap or expect without context
+let value = result.unwrap();
+
+// ✅ DO: Use ? for error propagation
+let value = result?;
+
+// ✅ DO: Use expect with a helpful message
+let value = result.expect("Config is validated at startup, this should never fail");
+```
+
+### Result and Option Handling
+
+Avoid using `match` for simple cases. Use the below methods if it makes the code cleaner.
+
+```rust
+// Use ? for error propagation
+do_something().map_err(|e| "Another error")?
+
+// Use if let for single arm matches
+if let Ok(value) = result {
+    outer.append(value);
+}
+
+// Use Option methods
+some_option.map(|x| x + 1)
+some_option.and_then(|x| func(x + 1))
+some_option.unwrap_or(1)
+some_option.ok_or("error")
+
+// Use Result methods
+result.map_err(|_| "Another error")
+```
+
+## Naming Conventions
+
+- Use `snake_case` for functions, variables, and modules
+- Use `PascalCase` for types, traits, and enum variants
+- Use `SCREAMING_SNAKE_CASE` for constants
+- Use descriptive names and avoid abbreviations
+
+## Documentation
+
+- All public APIs must have doc comments using `///`
+- Include examples for complex functions
+- Use `//` for internal comments that explain "why", not "what"
+
+## Memory Management
+
+- Use references (`&`) instead of owned values when possible
+- Use `&str` for string parameters when you don't need ownership
+- Use `String` for owned strings and return values
+- Pre-allocate collections with known sizes: `Vec::with_capacity()`
+
+## Error Types
+
+- Define domain-specific error types
+- Use `thiserror` crate for error derivation
+
+## Testing
+
+- Place unit tests in the same file using `#[cfg(test)]`
+- Use descriptive test names that describe the scenario
+- Follow the Arrange-Act-Assert pattern
+
+## Security
+
+- Always validate input parameters
+- Use constant-time operations for cryptographic comparisons
+
+## Additional Guidelines
+
+- Keep functions focused and single-purpose
+- Group imports: std library, external crates, local modules
+- Mark functions as `async` only when they perform async operations