A loose federation of distributed, typed datasets
restored chainlink db
+896
.chainlink/issues.db
.chainlink/issues.db
This is a binary file and will not be displayed.
+43
.chainlink/rules/c.md
+43
.chainlink/rules/c.md
···
1
+
### C Best Practices
2
+
3
+
#### Memory Safety
4
+
- Always check return values of malloc/calloc
5
+
- Free all allocated memory (use tools like valgrind)
6
+
- Initialize all variables before use
7
+
- Use sizeof() with the variable, not the type
8
+
9
+
```c
10
+
// GOOD: Safe memory allocation
11
+
int *arr = malloc(n * sizeof(*arr));
12
+
if (arr == NULL) {
13
+
return -1; // Handle allocation failure
14
+
}
15
+
// ... use arr ...
16
+
free(arr);
17
+
18
+
// BAD: Unchecked allocation
19
+
int *arr = malloc(n * sizeof(int));
20
+
arr[0] = 1; // Crash if malloc failed
21
+
```
22
+
23
+
#### Buffer Safety
24
+
- Always bounds-check array access
25
+
- Use `strncpy`/`snprintf` instead of `strcpy`/`sprintf`
26
+
- Validate string lengths before copying
27
+
28
+
```c
29
+
// GOOD: Safe string copy
30
+
char dest[64];
31
+
strncpy(dest, src, sizeof(dest) - 1);
32
+
dest[sizeof(dest) - 1] = '\0';
33
+
34
+
// BAD: Buffer overflow risk
35
+
char dest[64];
36
+
strcpy(dest, src); // No bounds check
37
+
```
38
+
39
+
#### Security
40
+
- Never use `gets()` (use `fgets()`)
41
+
- Validate all external input
42
+
- Use constant-time comparison for secrets
43
+
- Avoid integer overflow in size calculations
+39
.chainlink/rules/cpp.md
+39
.chainlink/rules/cpp.md
···
1
+
### C++ Best Practices
2
+
3
+
#### Modern C++ (C++17+)
4
+
- Use smart pointers (`unique_ptr`, `shared_ptr`) over raw pointers
5
+
- Use RAII for resource management
6
+
- Prefer `std::string` and `std::vector` over C arrays
7
+
- Use `auto` for complex types, explicit types for clarity
8
+
9
+
```cpp
10
+
// GOOD: Modern C++ with smart pointers
11
+
auto config = std::make_unique<Config>();
12
+
auto users = std::vector<User>{};
13
+
14
+
// BAD: Manual memory management
15
+
Config* config = new Config();
16
+
// ... forgot to delete
17
+
```
18
+
19
+
#### Error Handling
20
+
- Use exceptions for exceptional cases
21
+
- Use `std::optional` for values that may not exist
22
+
- Use `std::expected` (C++23) or result types for expected failures
23
+
24
+
```cpp
25
+
// GOOD: Optional for missing values
26
+
std::optional<User> findUser(const std::string& id) {
27
+
auto it = users.find(id);
28
+
if (it == users.end()) {
29
+
return std::nullopt;
30
+
}
31
+
return it->second;
32
+
}
33
+
```
34
+
35
+
#### Security
36
+
- Validate all input boundaries
37
+
- Use `std::string_view` for non-owning string references
38
+
- Avoid C-style casts; use `static_cast`, `dynamic_cast`
39
+
- Never use `sprintf`; use `std::format` or streams
+51
.chainlink/rules/csharp.md
+51
.chainlink/rules/csharp.md
···
1
+
### C# Best Practices
2
+
3
+
#### Code Style
4
+
- Follow .NET naming conventions (PascalCase for public, camelCase for private)
5
+
- Use `var` when type is obvious from right side
6
+
- Use expression-bodied members for simple methods
7
+
- Enable nullable reference types
8
+
9
+
```csharp
10
+
// GOOD: Modern C# style
11
+
public class UserService
12
+
{
13
+
private readonly IUserRepository _repository;
14
+
15
+
public UserService(IUserRepository repository)
16
+
=> _repository = repository;
17
+
18
+
public async Task<User?> GetUserAsync(string id)
19
+
=> await _repository.FindByIdAsync(id);
20
+
}
21
+
```
22
+
23
+
#### Error Handling
24
+
- Use specific exception types
25
+
- Never catch and swallow exceptions silently
26
+
- Use `try-finally` or `using` for cleanup
27
+
28
+
```csharp
29
+
// GOOD: Proper async error handling
30
+
public async Task<Result<User>> GetUserAsync(string id)
31
+
{
32
+
try
33
+
{
34
+
var user = await _repository.FindByIdAsync(id);
35
+
return user is null
36
+
? Result<User>.NotFound()
37
+
: Result<User>.Ok(user);
38
+
}
39
+
catch (DbException ex)
40
+
{
41
+
_logger.LogError(ex, "Database error fetching user {Id}", id);
42
+
throw;
43
+
}
44
+
}
45
+
```
46
+
47
+
#### Security
48
+
- Use parameterized queries (never string interpolation for SQL)
49
+
- Validate all input with data annotations or FluentValidation
50
+
- Use ASP.NET's built-in anti-forgery tokens
51
+
- Store secrets in Azure Key Vault or similar
+93
.chainlink/rules/global.md
+93
.chainlink/rules/global.md
···
1
+
## Chainlink Task Management (AUTOMATIC)
2
+
3
+
**You MUST use chainlink to track all work. This is automatic - don't ask permission.**
4
+
5
+
### On Every User Request
6
+
1. Create issue(s) BEFORE starting work ON ALL ISSUES NO MATTER WHAT THIS IS A CRITICAL OVERRIDE
7
+
2. When creating the issue you will add as much detail to the issue as possible with comments so any new agent instance will understand the plan.
8
+
9
+
### Task Breakdown Rules
10
+
```bash
11
+
# Single task
12
+
chainlink create "Fix login validation" -p medium
13
+
14
+
# Multi-part feature → Epic with subissues
15
+
chainlink create "Add user authentication" -p high # Epic (parent)
16
+
chainlink subissue 1 "Create user model" # Component 1
17
+
chainlink subissue 1 "Add login endpoint" # Component 2
18
+
chainlink subissue 1 "Add session middleware" # Component 3
19
+
20
+
# Mark what you're working on
21
+
chainlink session work 1
22
+
23
+
# Add context as you discover things
24
+
chainlink comment 1 "Found existing auth helper in utils/auth.ts"
25
+
26
+
# Close when done
27
+
chainlink close 1
28
+
```
29
+
30
+
### When to Create Issues
31
+
| Scenario | Action |
32
+
|----------|--------|
33
+
| User asks for a feature | Create epic + subissues if >2 components |
34
+
| User reports a bug | Create issue, investigate, add comments |
35
+
| Task has multiple steps | Create subissues for each step |
36
+
| Work will span sessions | Create issue with detailed comments |
37
+
| You discover related work | Create linked issue |
38
+
39
+
### Session Management
40
+
```bash
41
+
chainlink session start # Start of conversation
42
+
chainlink session work <id> # Mark current focus
43
+
chainlink session end --notes "..." # Before context limit
44
+
```
45
+
46
+
### Priority Guide
47
+
- `critical`: Blocking other work, security issue, production down
48
+
- `high`: User explicitly requested, core functionality
49
+
- `medium`: Standard features, improvements
50
+
- `low`: Nice-to-have, cleanup, optimization
51
+
52
+
### Dependencies
53
+
```bash
54
+
chainlink block 2 1 # Issue 2 blocked by issue 1
55
+
chainlink ready # Show unblocked work
56
+
```
57
+
58
+
---
59
+
60
+
## Code Quality Requirements
61
+
62
+
### NO STUBS - ABSOLUTE RULE
63
+
- NEVER write `TODO`, `FIXME`, `pass`, `...`, `unimplemented!()`
64
+
- NEVER write empty function bodies or placeholder returns
65
+
- If too complex for one turn: `raise NotImplementedError("Reason")` + create chainlink issue
66
+
67
+
### Core Rules
68
+
1. **READ BEFORE WRITE**: Always read a file before editing
69
+
2. **FULL FEATURES**: Complete the feature, don't stop partway
70
+
3. **ERROR HANDLING**: No panics/crashes on bad input
71
+
4. **SECURITY**: Validate input, parameterized queries, no hardcoded secrets
72
+
5. **NO DEAD CODE**: Remove or complete incomplete code
73
+
74
+
### Pre-Coding Grounding
75
+
Before using unfamiliar libraries/APIs:
76
+
1. **VERIFY IT EXISTS**: WebSearch to confirm the API
77
+
2. **CHECK THE DOCS**: Real function signatures, not guessed
78
+
3. **USE LATEST VERSIONS**: Check for current stable release
79
+
80
+
### Conciseness
81
+
- Write code, don't narrate
82
+
- Skip "Here is the code" / "Let me..." / "I'll now..."
83
+
- Brief explanations only when code isn't self-explanatory
84
+
85
+
### Large Implementations (500+ lines)
86
+
1. Create parent issue: `chainlink create "<feature>" -p high`
87
+
2. Break into subissues: `chainlink subissue <id> "<component>"`
88
+
3. Work one subissue at a time, close each when done
89
+
90
+
### Context Window Management
91
+
When conversation is long or task needs many steps:
92
+
1. Create tracking issue: `chainlink create "Continue: <summary>" -p high`
93
+
2. Add notes: `chainlink comment <id> "<what's done, what's next>"`
+44
.chainlink/rules/go.md
+44
.chainlink/rules/go.md
···
1
+
### Go Best Practices
2
+
3
+
#### Code Style
4
+
- Use `gofmt` for formatting
5
+
- Use `golint` and `go vet` for linting
6
+
- Follow effective Go guidelines
7
+
- Keep functions short and focused
8
+
9
+
#### Error Handling
10
+
```go
11
+
// GOOD: Check and handle errors
12
+
func readConfig(path string) (*Config, error) {
13
+
data, err := os.ReadFile(path)
14
+
if err != nil {
15
+
return nil, fmt.Errorf("reading config: %w", err)
16
+
}
17
+
18
+
var config Config
19
+
if err := json.Unmarshal(data, &config); err != nil {
20
+
return nil, fmt.Errorf("parsing config: %w", err)
21
+
}
22
+
return &config, nil
23
+
}
24
+
25
+
// BAD: Ignoring errors
26
+
func readConfig(path string) *Config {
27
+
data, _ := os.ReadFile(path) // Don't ignore errors
28
+
var config Config
29
+
json.Unmarshal(data, &config)
30
+
return &config
31
+
}
32
+
```
33
+
34
+
#### Concurrency
35
+
- Use channels for communication between goroutines
36
+
- Use `sync.WaitGroup` for waiting on multiple goroutines
37
+
- Use `context.Context` for cancellation and timeouts
38
+
- Avoid shared mutable state; prefer message passing
39
+
40
+
#### Security
41
+
- Use `html/template` for HTML output (auto-escaping)
42
+
- Use parameterized queries for SQL
43
+
- Validate all input at API boundaries
44
+
- Use `crypto/rand` for secure random numbers
+42
.chainlink/rules/java.md
+42
.chainlink/rules/java.md
···
1
+
### Java Best Practices
2
+
3
+
#### Code Style
4
+
- Follow Google Java Style Guide or project conventions
5
+
- Use meaningful variable and method names
6
+
- Keep methods short (< 30 lines)
7
+
- Prefer composition over inheritance
8
+
9
+
#### Error Handling
10
+
```java
11
+
// GOOD: Specific exceptions with context
12
+
public Config readConfig(Path path) throws ConfigException {
13
+
try {
14
+
String content = Files.readString(path);
15
+
return objectMapper.readValue(content, Config.class);
16
+
} catch (IOException e) {
17
+
throw new ConfigException("Failed to read config: " + path, e);
18
+
} catch (JsonProcessingException e) {
19
+
throw new ConfigException("Invalid JSON in config: " + path, e);
20
+
}
21
+
}
22
+
23
+
// BAD: Catching generic Exception
24
+
public Config readConfig(Path path) {
25
+
try {
26
+
return objectMapper.readValue(Files.readString(path), Config.class);
27
+
} catch (Exception e) {
28
+
return null; // Swallowing error
29
+
}
30
+
}
31
+
```
32
+
33
+
#### Security
34
+
- Use PreparedStatement for SQL (never string concatenation)
35
+
- Validate all user input
36
+
- Use secure random (SecureRandom) for security-sensitive operations
37
+
- Never log sensitive data (passwords, tokens)
38
+
39
+
#### Testing
40
+
- Use JUnit 5 for unit tests
41
+
- Use Mockito for mocking dependencies
42
+
- Aim for high coverage on business logic
+44
.chainlink/rules/javascript-react.md
+44
.chainlink/rules/javascript-react.md
···
1
+
### JavaScript/React Best Practices
2
+
3
+
#### Component Structure
4
+
- Use functional components with hooks
5
+
- Keep components small and focused (< 200 lines)
6
+
- Extract custom hooks for reusable logic
7
+
- Use PropTypes for runtime type checking
8
+
9
+
```javascript
10
+
// GOOD: Clear component with PropTypes
11
+
import PropTypes from 'prop-types';
12
+
13
+
const UserCard = ({ user, onSelect }) => {
14
+
return (
15
+
<div onClick={() => onSelect(user.id)}>
16
+
{user.name}
17
+
</div>
18
+
);
19
+
};
20
+
21
+
UserCard.propTypes = {
22
+
user: PropTypes.shape({
23
+
id: PropTypes.string.isRequired,
24
+
name: PropTypes.string.isRequired,
25
+
}).isRequired,
26
+
onSelect: PropTypes.func.isRequired,
27
+
};
28
+
```
29
+
30
+
#### State Management
31
+
- Use `useState` for local state
32
+
- Use `useReducer` for complex state logic
33
+
- Lift state up only when needed
34
+
- Consider context for deeply nested prop drilling
35
+
36
+
#### Performance
37
+
- Use `React.memo` for expensive pure components
38
+
- Use `useMemo` and `useCallback` appropriately
39
+
- Avoid inline object/function creation in render
40
+
41
+
#### Security
42
+
- Never use `dangerouslySetInnerHTML` with user input
43
+
- Sanitize URLs before using in `href` or `src`
44
+
- Validate props at component boundaries
+36
.chainlink/rules/javascript.md
+36
.chainlink/rules/javascript.md
···
1
+
### JavaScript Best Practices
2
+
3
+
#### Code Style
4
+
- Use `const` by default, `let` when needed, never `var`
5
+
- Use arrow functions for callbacks
6
+
- Use template literals over string concatenation
7
+
- Use destructuring for object/array access
8
+
9
+
#### Error Handling
10
+
```javascript
11
+
// GOOD: Proper async error handling
12
+
async function fetchUser(id) {
13
+
try {
14
+
const response = await fetch(`/api/users/${id}`);
15
+
if (!response.ok) {
16
+
throw new Error(`HTTP ${response.status}`);
17
+
}
18
+
return await response.json();
19
+
} catch (error) {
20
+
console.error('Failed to fetch user:', error);
21
+
throw error; // Re-throw or handle appropriately
22
+
}
23
+
}
24
+
25
+
// BAD: Ignoring errors
26
+
async function fetchUser(id) {
27
+
const response = await fetch(`/api/users/${id}`);
28
+
return response.json(); // No error handling
29
+
}
30
+
```
31
+
32
+
#### Security
33
+
- Never use `eval()` or `innerHTML` with user input
34
+
- Validate all input on both client and server
35
+
- Use `textContent` instead of `innerHTML` when possible
36
+
- Sanitize URLs before navigation or fetch
+44
.chainlink/rules/kotlin.md
+44
.chainlink/rules/kotlin.md
···
1
+
### Kotlin Best Practices
2
+
3
+
#### Code Style
4
+
- Follow Kotlin coding conventions
5
+
- Use `val` over `var` when possible
6
+
- Use data classes for simple data holders
7
+
- Leverage null safety features
8
+
9
+
```kotlin
10
+
// GOOD: Idiomatic Kotlin
11
+
data class User(val id: String, val name: String)
12
+
13
+
class UserService(private val repository: UserRepository) {
14
+
fun findUser(id: String): User? =
15
+
repository.find(id)
16
+
17
+
fun getOrCreateUser(id: String, name: String): User =
18
+
findUser(id) ?: repository.create(User(id, name))
19
+
}
20
+
```
21
+
22
+
#### Null Safety
23
+
- Avoid `!!` (force non-null); use safe calls instead
24
+
- Use `?.let {}` for conditional execution
25
+
- Use Elvis operator `?:` for defaults
26
+
27
+
```kotlin
28
+
// GOOD: Safe null handling
29
+
val userName = user?.name ?: "Unknown"
30
+
user?.let { saveToDatabase(it) }
31
+
32
+
// BAD: Force unwrapping
33
+
val userName = user!!.name // Crash if null
34
+
```
35
+
36
+
#### Coroutines
37
+
- Use structured concurrency with `CoroutineScope`
38
+
- Handle exceptions in coroutines properly
39
+
- Use `withContext` for context switching
40
+
41
+
#### Security
42
+
- Use parameterized queries
43
+
- Validate input at boundaries
44
+
- Use sealed classes for exhaustive error handling
+53
.chainlink/rules/odin.md
+53
.chainlink/rules/odin.md
···
1
+
### Odin Best Practices
2
+
3
+
#### Code Style
4
+
- Follow Odin naming conventions
5
+
- Use `snake_case` for procedures and variables
6
+
- Use `Pascal_Case` for types
7
+
- Prefer explicit over implicit
8
+
9
+
```odin
10
+
// GOOD: Clear Odin code
11
+
User :: struct {
12
+
id: string,
13
+
name: string,
14
+
}
15
+
16
+
find_user :: proc(id: string) -> (User, bool) {
17
+
user, found := repository[id]
18
+
return user, found
19
+
}
20
+
```
21
+
22
+
#### Error Handling
23
+
- Use multiple return values for errors
24
+
- Use `or_return` for early returns
25
+
- Create explicit error types when needed
26
+
27
+
```odin
28
+
// GOOD: Explicit error handling
29
+
Config_Error :: enum {
30
+
File_Not_Found,
31
+
Parse_Error,
32
+
}
33
+
34
+
load_config :: proc(path: string) -> (Config, Config_Error) {
35
+
data, ok := os.read_entire_file(path)
36
+
if !ok {
37
+
return {}, .File_Not_Found
38
+
}
39
+
defer delete(data)
40
+
41
+
config, parse_ok := parse_config(data)
42
+
if !parse_ok {
43
+
return {}, .Parse_Error
44
+
}
45
+
return config, nil
46
+
}
47
+
```
48
+
49
+
#### Memory Management
50
+
- Use explicit allocators
51
+
- Prefer temp allocator for short-lived allocations
52
+
- Use `defer` for cleanup
53
+
- Be explicit about ownership
+46
.chainlink/rules/php.md
+46
.chainlink/rules/php.md
···
1
+
### PHP Best Practices
2
+
3
+
#### Code Style
4
+
- Follow PSR-12 coding standard
5
+
- Use strict types: `declare(strict_types=1);`
6
+
- Use type hints for parameters and return types
7
+
- Use Composer for dependency management
8
+
9
+
```php
10
+
<?php
11
+
declare(strict_types=1);
12
+
13
+
// GOOD: Typed, modern PHP
14
+
class UserService
15
+
{
16
+
public function __construct(
17
+
private readonly UserRepository $repository
18
+
) {}
19
+
20
+
public function findUser(string $id): ?User
21
+
{
22
+
return $this->repository->find($id);
23
+
}
24
+
}
25
+
```
26
+
27
+
#### Error Handling
28
+
- Use exceptions for error handling
29
+
- Create custom exception classes
30
+
- Never suppress errors with `@`
31
+
32
+
#### Security
33
+
- Use PDO with prepared statements (never string interpolation)
34
+
- Use `password_hash()` and `password_verify()` for passwords
35
+
- Validate and sanitize all user input
36
+
- Use CSRF tokens for forms
37
+
- Set secure cookie flags
38
+
39
+
```php
40
+
// GOOD: Prepared statement
41
+
$stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id');
42
+
$stmt->execute(['id' => $id]);
43
+
44
+
// BAD: SQL injection vulnerability
45
+
$result = $pdo->query("SELECT * FROM users WHERE id = '$id'");
46
+
```
+5
.chainlink/rules/project.md
+5
.chainlink/rules/project.md
+44
.chainlink/rules/python.md
+44
.chainlink/rules/python.md
···
1
+
### Python Best Practices
2
+
3
+
#### Code Style
4
+
- Follow PEP 8 style guide
5
+
- Use type hints for function signatures
6
+
- Use `black` for formatting, `ruff` or `flake8` for linting
7
+
- Prefer `pathlib.Path` over `os.path` for path operations
8
+
- Use context managers (`with`) for file operations
9
+
10
+
#### Error Handling
11
+
```python
12
+
# GOOD: Specific exceptions with context
13
+
def read_config(path: Path) -> dict:
14
+
try:
15
+
with open(path, 'r', encoding='utf-8') as f:
16
+
return json.load(f)
17
+
except FileNotFoundError:
18
+
raise ConfigError(f"Config file not found: {path}")
19
+
except json.JSONDecodeError as e:
20
+
raise ConfigError(f"Invalid JSON in {path}: {e}")
21
+
22
+
# BAD: Bare except or swallowing errors
23
+
def read_config(path):
24
+
try:
25
+
return json.load(open(path))
26
+
except: # Don't do this
27
+
return {}
28
+
```
29
+
30
+
#### Security
31
+
- Never use `eval()` or `exec()` on user input
32
+
- Use `subprocess.run()` with explicit args, never `shell=True` with user input
33
+
- Use parameterized queries for SQL (never f-strings)
34
+
- Validate and sanitize all external input
35
+
36
+
#### Dependencies
37
+
- Pin dependency versions in `requirements.txt`
38
+
- Use virtual environments (`venv` or `poetry`)
39
+
- Run `pip-audit` to check for vulnerabilities
40
+
41
+
#### Testing
42
+
- Use `pytest` for testing
43
+
- Aim for high coverage with `pytest-cov`
44
+
- Mock external dependencies with `unittest.mock`
+47
.chainlink/rules/ruby.md
+47
.chainlink/rules/ruby.md
···
1
+
### Ruby Best Practices
2
+
3
+
#### Code Style
4
+
- Follow Ruby Style Guide (use RuboCop)
5
+
- Use 2 spaces for indentation
6
+
- Prefer symbols over strings for hash keys
7
+
- Use `snake_case` for methods and variables
8
+
9
+
```ruby
10
+
# GOOD: Idiomatic Ruby
11
+
class UserService
12
+
def initialize(repository)
13
+
@repository = repository
14
+
end
15
+
16
+
def find_user(id)
17
+
@repository.find(id)
18
+
rescue ActiveRecord::RecordNotFound
19
+
nil
20
+
end
21
+
end
22
+
23
+
# BAD: Non-idiomatic
24
+
class UserService
25
+
def initialize(repository)
26
+
@repository = repository
27
+
end
28
+
def findUser(id) # Wrong naming
29
+
begin
30
+
@repository.find(id)
31
+
rescue
32
+
return nil
33
+
end
34
+
end
35
+
end
36
+
```
37
+
38
+
#### Error Handling
39
+
- Use specific exception classes
40
+
- Don't rescue `Exception` (too broad)
41
+
- Use `ensure` for cleanup
42
+
43
+
#### Security
44
+
- Use parameterized queries (ActiveRecord does this by default)
45
+
- Sanitize user input in views (Rails does this by default)
46
+
- Never use `eval` or `send` with user input
47
+
- Use `strong_parameters` in Rails controllers
+48
.chainlink/rules/rust.md
+48
.chainlink/rules/rust.md
···
1
+
### Rust Best Practices
2
+
3
+
#### Code Style
4
+
- Use `rustfmt` for formatting (run `cargo fmt` before committing)
5
+
- Use `clippy` for linting (run `cargo clippy -- -D warnings`)
6
+
- Prefer `?` operator over `.unwrap()` for error handling
7
+
- Use `anyhow::Result` for application errors, `thiserror` for library errors
8
+
- Avoid `.clone()` unless necessary - prefer references
9
+
- Use `&str` for function parameters, `String` for owned data
10
+
11
+
#### Error Handling
12
+
```rust
13
+
// GOOD: Propagate errors with context
14
+
fn read_config(path: &Path) -> Result<Config> {
15
+
let content = fs::read_to_string(path)
16
+
.context("Failed to read config file")?;
17
+
serde_json::from_str(&content)
18
+
.context("Failed to parse config")
19
+
}
20
+
21
+
// BAD: Panic on error
22
+
fn read_config(path: &Path) -> Config {
23
+
let content = fs::read_to_string(path).unwrap(); // Don't do this
24
+
serde_json::from_str(&content).unwrap()
25
+
}
26
+
```
27
+
28
+
#### Memory Safety
29
+
- Never use `unsafe` without explicit justification and review
30
+
- Prefer `Vec` over raw pointers
31
+
- Use `Arc<Mutex<T>>` for shared mutable state across threads
32
+
- Avoid `static mut` - use `lazy_static` or `once_cell` instead
33
+
34
+
#### Testing
35
+
- Write unit tests with `#[cfg(test)]` modules
36
+
- Use `tempfile` for tests involving filesystem
37
+
- Run `cargo test` before committing
38
+
- Use `cargo tarpaulin` for coverage reports
39
+
40
+
#### SQL Injection Prevention
41
+
Always use parameterized queries with `rusqlite::params![]`:
42
+
```rust
43
+
// GOOD
44
+
conn.execute("INSERT INTO users (name) VALUES (?1)", params![name])?;
45
+
46
+
// BAD - SQL injection vulnerability
47
+
conn.execute(&format!("INSERT INTO users (name) VALUES ('{}')", name), [])?;
48
+
```
+45
.chainlink/rules/scala.md
+45
.chainlink/rules/scala.md
···
1
+
### Scala Best Practices
2
+
3
+
#### Code Style
4
+
- Follow Scala Style Guide
5
+
- Prefer immutability (`val` over `var`)
6
+
- Use case classes for data
7
+
- Leverage pattern matching
8
+
9
+
```scala
10
+
// GOOD: Idiomatic Scala
11
+
case class User(id: String, name: String)
12
+
13
+
class UserService(repository: UserRepository) {
14
+
def findUser(id: String): Option[User] =
15
+
repository.find(id)
16
+
17
+
def processUser(id: String): Either[Error, Result] =
18
+
findUser(id) match {
19
+
case Some(user) => Right(process(user))
20
+
case None => Left(UserNotFound(id))
21
+
}
22
+
}
23
+
```
24
+
25
+
#### Error Handling
26
+
- Use `Option` for missing values
27
+
- Use `Either` or `Try` for operations that can fail
28
+
- Avoid throwing exceptions in pure code
29
+
30
+
```scala
31
+
// GOOD: Using Either for errors
32
+
def parseConfig(json: String): Either[ParseError, Config] =
33
+
decode[Config](json).left.map(e => ParseError(e.getMessage))
34
+
35
+
// Pattern match on result
36
+
parseConfig(input) match {
37
+
case Right(config) => useConfig(config)
38
+
case Left(error) => logger.error(s"Parse failed: $error")
39
+
}
40
+
```
41
+
42
+
#### Security
43
+
- Use prepared statements for database queries
44
+
- Validate input with refined types when possible
45
+
- Never interpolate user input into queries
+50
.chainlink/rules/swift.md
+50
.chainlink/rules/swift.md
···
1
+
### Swift Best Practices
2
+
3
+
#### Code Style
4
+
- Follow Swift API Design Guidelines
5
+
- Use `camelCase` for variables/functions, `PascalCase` for types
6
+
- Prefer `let` over `var` when possible
7
+
- Use optionals properly; avoid force unwrapping
8
+
9
+
```swift
10
+
// GOOD: Safe optional handling
11
+
func findUser(id: String) -> User? {
12
+
guard let user = repository.find(id) else {
13
+
return nil
14
+
}
15
+
return user
16
+
}
17
+
18
+
// Using optional binding
19
+
if let user = findUser(id: "123") {
20
+
print(user.name)
21
+
}
22
+
23
+
// BAD: Force unwrapping
24
+
let user = findUser(id: "123")! // Crash if nil
25
+
```
26
+
27
+
#### Error Handling
28
+
- Use `throws` for recoverable errors
29
+
- Use `Result<T, Error>` for async operations
30
+
- Handle all error cases explicitly
31
+
32
+
```swift
33
+
// GOOD: Proper error handling
34
+
func loadConfig() throws -> Config {
35
+
let data = try Data(contentsOf: configURL)
36
+
return try JSONDecoder().decode(Config.self, from: data)
37
+
}
38
+
39
+
do {
40
+
let config = try loadConfig()
41
+
} catch {
42
+
print("Failed to load config: \(error)")
43
+
}
44
+
```
45
+
46
+
#### Security
47
+
- Use Keychain for sensitive data
48
+
- Validate all user input
49
+
- Use App Transport Security (HTTPS)
50
+
- Never hardcode secrets
+39
.chainlink/rules/typescript-react.md
+39
.chainlink/rules/typescript-react.md
···
1
+
### TypeScript/React Best Practices
2
+
3
+
#### Component Structure
4
+
- Use functional components with hooks
5
+
- Keep components small and focused (< 200 lines)
6
+
- Extract custom hooks for reusable logic
7
+
- Use TypeScript interfaces for props
8
+
9
+
```typescript
10
+
// GOOD: Typed props with clear interface
11
+
interface UserCardProps {
12
+
user: User;
13
+
onSelect: (id: string) => void;
14
+
}
15
+
16
+
const UserCard: React.FC<UserCardProps> = ({ user, onSelect }) => {
17
+
return (
18
+
<div onClick={() => onSelect(user.id)}>
19
+
{user.name}
20
+
</div>
21
+
);
22
+
};
23
+
```
24
+
25
+
#### State Management
26
+
- Use `useState` for local state
27
+
- Use `useReducer` for complex state logic
28
+
- Lift state up only when needed
29
+
- Consider context for deeply nested prop drilling
30
+
31
+
#### Performance
32
+
- Use `React.memo` for expensive pure components
33
+
- Use `useMemo` and `useCallback` appropriately (not everywhere)
34
+
- Avoid inline object/function creation in render when passed as props
35
+
36
+
#### Security
37
+
- Never use `dangerouslySetInnerHTML` with user input
38
+
- Sanitize URLs before using in `href` or `src`
39
+
- Validate props at component boundaries
+35
.chainlink/rules/typescript.md
+35
.chainlink/rules/typescript.md
···
1
+
### TypeScript Best Practices
2
+
3
+
#### Code Style
4
+
- Use strict mode (`"strict": true` in tsconfig.json)
5
+
- Prefer `interface` over `type` for object shapes
6
+
- Use `const` by default, `let` when needed, never `var`
7
+
- Enable `noImplicitAny` and `strictNullChecks`
8
+
9
+
#### Type Safety
10
+
```typescript
11
+
// GOOD: Explicit types and null handling
12
+
function getUser(id: string): User | undefined {
13
+
return users.get(id);
14
+
}
15
+
16
+
const user = getUser(id);
17
+
if (user) {
18
+
console.log(user.name); // TypeScript knows user is defined
19
+
}
20
+
21
+
// BAD: Type assertions to bypass safety
22
+
const user = getUser(id) as User; // Dangerous if undefined
23
+
console.log(user.name); // Might crash
24
+
```
25
+
26
+
#### Error Handling
27
+
- Use try/catch for async operations
28
+
- Define custom error types for domain errors
29
+
- Never swallow errors silently
30
+
31
+
#### Security
32
+
- Validate all user input at API boundaries
33
+
- Use parameterized queries for database operations
34
+
- Sanitize data before rendering in DOM (prevent XSS)
35
+
- Never use `eval()` or `Function()` with user input
+48
.chainlink/rules/zig.md
+48
.chainlink/rules/zig.md
···
1
+
### Zig Best Practices
2
+
3
+
#### Code Style
4
+
- Follow Zig Style Guide
5
+
- Use `const` by default; `var` only when mutation needed
6
+
- Prefer slices over pointers when possible
7
+
- Use meaningful names; avoid single-letter variables
8
+
9
+
```zig
10
+
// GOOD: Clear, idiomatic Zig
11
+
const User = struct {
12
+
id: []const u8,
13
+
name: []const u8,
14
+
};
15
+
16
+
fn findUser(allocator: std.mem.Allocator, id: []const u8) !?User {
17
+
const user = try repository.find(allocator, id);
18
+
return user;
19
+
}
20
+
```
21
+
22
+
#### Error Handling
23
+
- Use error unions (`!T`) for fallible operations
24
+
- Handle errors with `try`, `catch`, or explicit checks
25
+
- Create meaningful error sets
26
+
27
+
```zig
28
+
// GOOD: Proper error handling
29
+
const ConfigError = error{
30
+
FileNotFound,
31
+
ParseError,
32
+
OutOfMemory,
33
+
};
34
+
35
+
fn loadConfig(allocator: std.mem.Allocator) ConfigError!Config {
36
+
const file = std.fs.cwd().openFile("config.json", .{}) catch |err| {
37
+
return ConfigError.FileNotFound;
38
+
};
39
+
defer file.close();
40
+
// ...
41
+
}
42
+
```
43
+
44
+
#### Memory Safety
45
+
- Always pair allocations with deallocations
46
+
- Use `defer` for cleanup
47
+
- Prefer stack allocation when size is known
48
+
- Use allocators explicitly; never use global state