+42

modules/opencode/agents/ask.md

··· 1 1 + --- 2 2 + description: Exploratory read-only agent for searching, analyzing, and asking questions about the codebase. 3 3 + mode: primary 4 4 + temperature: 0.1 5 5 + tools: 6 6 + tools: 7 7 + read: true 8 8 + glob: true 9 9 + grep: true 10 10 + edit: false 11 11 + bash: true 12 12 + todowrite: false 13 13 + todoread: false 14 14 + permission: 15 15 + edit: deny 16 16 + bash: 17 17 + "*": ask 18 18 + "ls *": allow 19 19 + "cat *": allow 20 20 + "grep *": allow 21 21 + "find *": allow 22 22 + "rg *": allow 23 23 + "fd *": allow 24 24 + "git diff*": allow 25 25 + "git log*": allow 26 26 + "git status": allow 27 27 + "git show*": allow 28 28 + --- 29 29 + 30 30 + You are the "Ask" agent, a senior software architect and codebase explorer. Your purpose is entirely exploratory and analytical. The user interacting with you is a domain expert and fellow senior engineer. They will ask you to search for things, trace execution paths, and analyze high-level architectural patterns or complex implementation details. 31 31 + 32 32 + # Core Directives: 33 33 + 34 34 + 1. **Strictly Read-Only:** You operate in a purely exploratory environment. Do not attempt to modify, refactor, or write new code to the file system. 35 35 + 36 36 + 2. **Active Exploration & Precision:** Leverage read-only bash commands (`grep`, `rg`, `find`, `cat`, `ls`) to actively traverse the codebase. Do not guess—base all your answers on actual code reality. Always ground your analysis with precise, valid file paths and line references. 37 37 + 38 38 + 3. **Expert-Level Analysis:** Communicate peer-to-peer. Assume the user has deep technical fluency. Focus your explanations on architectural patterns, system constraints, data flow, and idiomatic usage. Gloss over basic syntax or trivial lexical differences. Get straight to the point without introductory fluff or over-explaining standard concepts. 39 39 + 40 40 + 4. **Proactive Investigation:** If given a high-level query (e.g., "Where is the auth middleware?"), autonomously locate the relevant implementations, trace the usage patterns, and present a concise, highly technical summary of the underlying mechanics. 41 41 + 42 42 + 5. **Boundary Enforcement:** If the user requests code modifications, politely decline, remind them of your read-only constraints, and advise them to use the `build` agent to apply changes.

+1 -5

modules/opencode/default.nix

··· 5 5 ... 6 6 }: 7 7 let 8 8 - rulesDir = ./rules; 9 9 - 10 8 opencodePkg = pkgs.symlinkJoin { 11 9 name = "opencode.wrapped"; 12 10 paths = [ pkgs.opencode ]; 13 11 buildInputs = [ pkgs.makeWrapper ]; 14 12 postBuild = '' 15 13 wrapProgram $out/bin/opencode \ 16 16 - --set SHELL ${lib.getExe pkgs.bash} \ 17 17 - --set-default LANGRULES_DIR ${rulesDir} 14 14 + --set SHELL ${lib.getExe pkgs.bash} 18 15 ''; 19 16 }; 20 17 ··· 34 31 enableMcpIntegration = cfg.enableMcp; 35 32 settings = { 36 33 inherit (cfg) theme; 37 37 - # plugin = [ "git@tangled.org:karitham.dev/langrules-opencode" ]; 38 34 permission = { 39 35 todoread = "deny"; 40 36 todowrite = "deny";

-56

modules/opencode/rules/global.md

··· 1 1 - # Global Coding Rules 2 2 - 3 3 - ## NO STUBS - ABSOLUTE RULE 4 4 - 5 5 - - NEVER write `TODO`, `FIXME`, `pass`, `...`, `unimplemented!()` 6 6 - - NEVER write empty function bodies or placeholder returns 7 7 - - If too complex for one turn: throw an error/exception with a clear reason 8 8 - 9 9 - ## Core Rules 10 10 - 11 11 - 1. **READ BEFORE WRITE**: Always read a file before editing. 12 12 - 2. **FULL FEATURES**: Complete the feature, don't stop partway. 13 13 - 3. **ERROR HANDLING**: No panics/crashes on bad input. 14 14 - 4. **SECURITY**: Validate input, parameterized queries, no hardcoded secrets. 15 15 - 5. **NO DEAD CODE**: Remove or complete incomplete code. 16 16 - 17 17 - ## Chainlink Lifecycle Management 18 18 - 19 19 - You MUST use Chainlink to track all work: 20 20 - 21 21 - - **Session Start**: `chainlink session start` - shows previous handoff 22 22 - - **Session Work**: `chainlink session work <id>` - mark current focus 23 23 - - **Progress**: `chainlink comment <id> "..."` - update regularly 24 24 - - **Session End**: `chainlink session end --notes "..."` - REQUIRED before stopping 25 25 - 26 26 - ### Handoff Notes Format 27 27 - 28 28 - ```markdown 29 29 - **Accomplished:** 30 30 - - Completed feature X 31 31 - - Added tests for Y 32 32 - 33 33 - **In Progress:** 34 34 - - Working on feature Z 35 35 - 36 36 - **Next:** 37 37 - - Complete feature Z 38 38 - - Run tests 39 39 - 40 40 - **Blockers:** 41 41 - - None 42 42 - ``` 43 43 - 44 44 - ## Code Quality Requirements 45 45 - 46 46 - - **NO DEAD CODE**: Remove unused functions, variables, imports 47 47 - - **NO HARDCODED SECRETS**: Use environment variables, configs 48 48 - - **COMMIT FREQUENTLY**: Small, focused commits 49 49 - - **DESCRIPTIVE COMMITS**: Explain WHY, not just WHAT 50 50 - 51 51 - ## Security 52 52 - 53 53 - - Validate ALL inputs (user, network, config) 54 54 - - Use parameterized queries for database access 55 55 - - Never log sensitive data (passwords, tokens, keys) 56 56 - - Follow principle of least privilege

-95

modules/opencode/rules/go.md

··· 1 1 - ### Go Best Practices 2 2 - 3 3 - Follow [Effective Go](https://go.dev/doc/effective_go) and [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments). 4 4 - 5 5 - #### Code Style & Structure 6 6 - 7 7 - - **Existing Style**: The best Go style is the existing style. Adapt to existing patterns and conventions in the codebase as much as possible. 8 8 - - **Small Interfaces**: Keep interfaces small (often 1-3 methods). "The bigger the interface, the weaker the abstraction." 9 9 - - **Deep Modules**: Design modules with simple interfaces that hide significant complexity (deep vs. shallow). 10 10 - - **Align Left**: Keep the "happy path" aligned to the left. 11 11 - - **Early Returns**: Use guard clauses to handle errors and edge cases early, reducing nesting. 12 12 - - **Avoid Else**: Avoid `else` blocks; they often indicate complex branching that can be flattened with early returns. 13 13 - - **No Naked Returns**: Avoid using named return parameters for actual returns. 14 14 - - **Latest Features**: Leverage modern Go features (generics, `any`, `net/http` routing enhancements, `log/slog`, `t.Context()`). 15 15 - - **Simple Functions**: Write small, focused functions that do one thing well. 16 16 - - **Avoid God Objects**: Don't create types that try to do everything. Use composition. 17 17 - - **Pure Code**: Prefer pure functions where possible. 18 18 - - **Easy to Mock**: Accept interfaces, return structs. Use dependency injection. 19 19 - 20 20 - #### Error Handling 21 21 - 22 22 - Always check and handle errors immediately. Wrap errors with context. 23 23 - 24 24 - ```go 25 25 - // GOOD: Early returns, aligned left, no else 26 26 - func readConfig(path string) (*Config, error) { 27 27 - data, err := os.ReadFile(path) 28 28 - if err != nil { 29 29 - return nil, fmt.Errorf("read config: %w", err) 30 30 - } 31 31 - 32 32 - var config Config 33 33 - if err := json.Unmarshal(data, &config); err != nil { 34 34 - return nil, fmt.Errorf("parse config: %w", err) 35 35 - } 36 36 - 37 37 - return &config, nil 38 38 - } 39 39 - 40 40 - // BAD: Nested, use of else, harder to follow 41 41 - func readConfig(path string) (*Config, error) { 42 42 - data, err := os.ReadFile(path) 43 43 - if err == nil { 44 44 - var config Config 45 45 - err = json.Unmarshal(data, &config) 46 46 - if err == nil { 47 47 - return &config, nil 48 48 - } else { 49 49 - return nil, err 50 50 - } 51 51 - } else { 52 52 - return nil, err 53 53 - } 54 54 - } 55 55 - ``` 56 56 - 57 57 - #### Concurrency & Sync 58 58 - 59 59 - - **Package sync**: Use `sync.Mutex`, `sync.RWMutex`, `sync.Once`, and `sync.Pool` extensively. 60 60 - - **sync.WaitGroup**: Use for waiting on multiple goroutines. 61 61 - - **Channels**: Use for coordination between goroutines. 62 62 - - **Context**: Always propagate `context.Context`. Use `t.Context()` in tests for automatic cleanup. 63 63 - - **Atomic**: Use `sync/atomic` for simple counter/state updates. 64 64 - 65 65 - #### Testing 66 66 - 67 67 - Use the standard `testing` package effectively. 68 68 - 69 69 - - **Table-Driven Tests**: Use anonymous structs for test cases with clear `name`, `got`, and `want` fields. 70 70 - - **t.Context()**: Use `t.Context()` for test-scoped context that cancels when the test finishes. 71 71 - - **Few Functions, Good Tables**: Prefer one robust test function with a comprehensive table over many small test functions. 72 72 - - **Helper Functions**: Use `t.Helper()` in functions that assist in testing to keep stack traces clean. 73 73 - 74 74 - ```go 75 75 - func TestSum(t *testing.T) { 76 76 - tests := []struct { 77 77 - name string 78 78 - args []int 79 79 - want int 80 80 - }{ 81 81 - {"empty", []int{}, 0}, 82 82 - {"single", []int{1}, 1}, 83 83 - {"multiple", []int{1, 2, 3}, 6}, 84 84 - {"negative", []int{1, -1}, 0}, 85 85 - } 86 86 - 87 87 - for _, tt := range tests { 88 88 - t.Run(tt.name, func(t *testing.T) { 89 89 - if got := Sum(tt.args); got != tt.want { 90 90 - t.Errorf("Sum() = %v, want %v", got, tt.want) 91 91 - } 92 92 - }) 93 93 - } 94 94 - } 95 95 - ```

-36

modules/opencode/rules/javascript.md

··· 1 1 - ### JavaScript Best Practices 2 2 - 3 3 - #### Code Style 4 4 - - Use `const` by default, `let` when needed, never `var` 5 5 - - Use arrow functions for callbacks 6 6 - - Use template literals over string concatenation 7 7 - - Use destructuring for object/array access 8 8 - 9 9 - #### Error Handling 10 10 - ```javascript 11 11 - // GOOD: Proper async error handling 12 12 - async function fetchUser(id) { 13 13 - try { 14 14 - const response = await fetch(`/api/users/${id}`); 15 15 - if (!response.ok) { 16 16 - throw new Error(`HTTP ${response.status}`); 17 17 - } 18 18 - return await response.json(); 19 19 - } catch (error) { 20 20 - console.error('Failed to fetch user:', error); 21 21 - throw error; // Re-throw or handle appropriately 22 22 - } 23 23 - } 24 24 - 25 25 - // BAD: Ignoring errors 26 26 - async function fetchUser(id) { 27 27 - const response = await fetch(`/api/users/${id}`); 28 28 - return response.json(); // No error handling 29 29 - } 30 30 - ``` 31 31 - 32 32 - #### Security 33 33 - - Never use `eval()` or `innerHTML` with user input 34 34 - - Validate all input on both client and server 35 35 - - Use `textContent` instead of `innerHTML` when possible 36 36 - - Sanitize URLs before navigation or fetch

-306

modules/opencode/rules/nix.md

··· 1 1 - # Nix Best Practices 2 2 - 3 3 - ## Code Style 4 4 - 5 5 - - Use `nixfmt` for formatting (set as formatter in flake, run `nix fmt` before committing) 6 6 - - Follow the [Nixpkgs contributing guide](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md) for style conventions 7 7 - - Use descriptive variable names that explain purpose 8 8 - - Prefer `let ... in` blocks for local bindings over deep nesting 9 9 - - Keep derivations and functions small and composable 10 10 - - Use `lib.mkIf`, `lib.mkWhen`, `lib.optionals` for conditional logic 11 11 - - Use `lib.getExe` and `lib.getExe'` for accessing package executables 12 12 - 13 13 - ## Error Handling 14 14 - 15 15 - ```nix 16 16 - # GOOD: Proper error handling with builtins.tryEval 17 17 - let 18 18 - configPath = ./config.json; 19 19 - config = builtins.tryEval (builtins.fromJSON (builtins.readFile configPath)); 20 20 - in 21 21 - if config.success then config.value else throw "Failed to parse config" 22 22 - 23 23 - # GOOD: Using assert statements for validation 24 24 - assert lib.assertMsg (cfg.port > 0 && cfg.port < 65536) "Port must be between 1 and 65535"; 25 25 - cfg 26 26 - 27 27 - # GOOD: Using lib.mapAttrs' with lib.nameValuePair for building attribute sets 28 28 - lib.mapAttrs' (argName: argValue: 29 29 - lib.nameValuePair "${argName}+${dir.name}" { 30 30 - action = { 31 31 - "${argValue}-${dir.value}" = [ ]; 32 32 - }; 33 33 - } 34 34 - ) act 35 35 - 36 36 - # BAD: Silent failures or incomplete error messages 37 37 - let 38 38 - data = builtins.readFile configPath; 39 39 - config = builtins.fromJSON data; # Will throw cryptic error if invalid 40 40 - in config 41 41 - ``` 42 42 - 43 43 - ## Nix Module System 44 44 - 45 45 - - Use `lib.mkOptionType`, `lib.mkDefault`, `lib.mkForce` appropriately 46 46 - - Prefer `mkOption` with proper `type`, `default`, and `description` fields 47 47 - - Use `mkIf` for conditional module options rather than deep nesting 48 48 - - Keep modules focused - one module per responsibility 49 49 - - Use `imports` to compose modules rather than duplicating code 50 50 - - Use `lib.getExe pkgs.packageName` for executable paths in configuration 51 51 - 52 52 - ```nix 53 53 - # GOOD: Well-structured module option 54 54 - { lib, config, ... }: 55 55 - { 56 56 - options.my.username = lib.mkOption { 57 57 - type = lib.types.str; 58 58 - description = "The username for the current user."; 59 59 - default = "kar"; 60 60 - }; 61 61 - 62 62 - config = lib.mkIf (config.my.username != "root") { 63 63 - users.users.${config.my.username} = { 64 64 - home = "/home/${config.my.username}"; 65 65 - initialPassword = ""; 66 66 - isNormalUser = true; 67 67 - extraGroups = [ 68 68 - "networkmanager" 69 69 - "docker" 70 70 - "wheel" 71 71 - ]; 72 72 - }; 73 73 - }; 74 74 - } 75 75 - ``` 76 76 - 77 77 - ## Flake Patterns 78 78 - 79 79 - - Use `flake-parts` for modular flake structure 80 80 - - Use `withSystem` for system-specific configuration 81 81 - - Provide `devShells`, `packages`, `checks`, `formatter` per system 82 82 - - Lock `nixpkgs` reference using channel URLs or specific revisions 83 83 - - Provide formatter and linter in `devShells` 84 84 - - Use `nixConfig` for Nix configuration (experimental features, substituters) 85 85 - 86 86 - ## System Management 87 87 - 88 88 - - Use `easy-hosts` for organizing hosts by class (desktop, server, wsl) and tags 89 89 - - Define shared modules for all systems in `config.easy-hosts.shared.modules` 90 90 - - Use perClass and perTag for class-specific and tag-specific modules 91 91 - - Use `mkSystem'` for creating individual systems with proper specialArgs 92 92 - 93 93 - ## Overlay Patterns 94 94 - 95 95 - - Use `overrideAttrs` for patching existing packages 96 96 - - Use `fetchurl` or `fetchFromGitHub` for patches with hash verification 97 97 - - Use `callPackage` to add packages to overlay 98 98 - - Keep overlays focused and well-documented 99 99 - 100 100 - ## Package Building 101 101 - 102 102 - - Use `pkgs.buildGoModule` for Go packages with proper vendorHash 103 103 - - Use `pkgs.fetchFromGitHub` for GitHub sources with hash verification 104 104 - - Set `env.CGO_ENABLED`, `flags`, and `ldflags` appropriately for Go 105 105 - - Include proper `meta` with description, homepage, license, maintainers 106 106 - - Use `trimpath` and static linking flags for production binaries 107 107 - 108 108 - ## Security 109 109 - 110 110 - - Never commit secrets or API keys in Nix files 111 111 - - Use `sops-nix` for secrets management in production 112 112 - - Use sandbox mode in `nix.conf` (`sandbox = true`) for builds 113 113 - - Review network access in derivations - use `allowedRequisites` for purity 114 114 - - Use `fetchFromGitHub` or `fetchurl` with hash verification 115 115 - 116 116 - ## Dependency Management 117 117 - 118 118 - - Use specific Git revisions/commits for Git dependencies (not branches) 119 119 - - Always include `sha256` hash for fetch functions 120 120 - - Use `inputs.nixpkgs.follows` to avoid duplicating inputs 121 121 - - Pin `nixpkgs` in production configurations using `flake.lock` 122 122 - - Prefer `flake-inputs` over `builtins.fetchTarball` for external sources 123 123 - - Use `callPackage` pattern for package dependencies 124 124 - 125 125 - ## Testing 126 126 - 127 127 - - Use `nix-instantiate --parse` to check for syntax errors 128 128 - - Use `nix-build` with `-A` to test specific attributes 129 129 - - Write checks in `perSystem.checks` for package testing 130 130 - - Use `nix flake check` for flake validation 131 131 - - Test modules with `nixos-rebuild dry-build` or `nixos-rebuild test` 132 132 - 133 133 - ## Evaluation 134 134 - 135 135 - - Use `lib.warnIf` and `lib.deprecated` for deprecation notices 136 136 - - Avoid `builtins.trace` in production code (use for debugging only) 137 137 - - Use `lib.lists.foldl'` or `lib.lists.foldl'` for strict left folds 138 138 - - Prefer `lib.mapAttrs` and `lib.mapAttrs'` over `builtins.map` for attribute sets 139 139 - - Use `lib.filterAttrs` for filtering attributes 140 140 - - Use `lib.mergeAttrsList` for merging lists of attribute sets 141 141 - - Use `lib.attrsToList` for converting attributes to list of name-value pairs 142 142 - 143 143 - ## Performance 144 144 - 145 145 - - Use `lib.optionals` and `lib.concatMap` for list operations 146 146 - - Avoid deep recursion - use `foldl'` for accumulation 147 147 - - Use `overrideAttrs` for modifying packages instead of rewriting 148 148 - - Prefer `stdenv.mkDerivation` over raw `derivation` for packages 149 149 - - Use `pkgs.callPackage` with explicit arguments for clarity 150 150 - 151 151 - ## Home-Manager Module System 152 152 - 153 153 - Home-manager modules manage user-level configuration (home directory, user packages, programs). 154 154 - 155 155 - ### Module Structure 156 156 - 157 157 - ``` 158 158 - modules/ 159 159 - dev/ 160 160 - home.nix # Home-manager module with osConfig parameter 161 161 - nixos.nix # NixOS module importing home.nix via homeModules 162 162 - shell/ 163 163 - default.nix # Imports sub-modules 164 164 - nushell.nix # Actual configuration 165 165 - ``` 166 166 - 167 167 - ### Home-Manager Module Pattern 168 168 - 169 169 - ```nix 170 170 - # modules/dev/shell/default.nix 171 171 - { 172 172 - imports = [ 173 173 - ./atuin.nix 174 174 - ./nushell.nix 175 175 - ./starship.nix 176 176 - ./zellij.nix 177 177 - ]; 178 178 - } 179 179 - ``` 180 180 - 181 181 - ### Home-Manager with osConfig 182 182 - 183 183 - ```nix 184 184 - # modules/dev/home.nix 185 185 - { 186 186 - osConfig ? { }, 187 187 - lib, 188 188 - ... 189 189 - }: 190 190 - let 191 191 - inherit (lib) mkEnableOption; 192 192 - in 193 193 - { 194 194 - # Inherit options from NixOS module configuration 195 195 - config.dev = { 196 196 - inherit (osConfig.dev or { }) 197 197 - shell 198 198 - editor 199 199 - vcs 200 200 - tools 201 201 - ; 202 202 - }; 203 203 - 204 204 - # Define options (mirrors NixOS module) 205 205 - options.dev = { 206 206 - enable = mkEnableOption "all development tools"; 207 207 - shell.enable = mkEnableOption "shell-related tools"; 208 208 - editor.enable = mkEnableOption "editor tools"; 209 209 - vcs.enable = mkEnableOption "version control tools"; 210 210 - tools.enable = mkEnableOption "development utilities"; 211 211 - }; 212 212 - 213 213 - # Import sub-modules 214 214 - imports = [ 215 215 - ./shell 216 216 - ./editor 217 217 - ./vcs 218 218 - ./tools 219 219 - ]; 220 220 - } 221 221 - ``` 222 222 - 223 223 - ### Flake Integration 224 224 - 225 225 - ```nix 226 226 - # flake.nix modules section 227 227 - { 228 228 - imports = [ ../systems ]; 229 229 - 230 230 - perSystem = { ... }: { 231 231 - # ... 232 232 - }; 233 233 - 234 234 - flake = { 235 235 - homeModules = { 236 236 - dev = import ./dev/home.nix; 237 237 - desktop = import ./desktop/home.nix; 238 238 - }; 239 239 - 240 240 - nixosModules = { 241 241 - dev = import ./dev/nixos.nix; 242 242 - desktop = import ./desktop/nixos.nix; 243 243 - }; 244 244 - }; 245 245 - } 246 246 - ``` 247 247 - 248 248 - ### Usage in System Configuration 249 249 - 250 250 - ```nix 251 251 - # systems/kiwi.nix (NixOS) 252 252 - { 253 253 - imports = [ 254 254 - inputs.self.nixosModules.dev 255 255 - # ... other modules 256 256 - ]; 257 257 - 258 258 - dev.enable = true; 259 259 - dev.shell.enable = true; 260 260 - } 261 261 - ``` 262 262 - 263 263 - ```nix 264 264 - # modules/desktop/home.nix (Home-Manager) 265 265 - { config, self, ... }: 266 266 - { 267 267 - imports = [ 268 268 - self.homeModules.dev 269 269 - # ... other home modules 270 270 - ]; 271 271 - 272 272 - dev.enable = true; 273 273 - } 274 274 - ``` 275 275 - 276 276 - ### Key Differences from NixOS Modules 277 277 - 278 278 - | Aspect | NixOS Module | Home-Manager Module | 279 279 - |--------|--------------|---------------------| 280 280 - | Special args | `{ config, lib, pkgs, ... }` | `{ config, lib, pkgs, osConfig ? {}, ... }` | 281 281 - | System config | Direct access to `config.*` | Inherits via `osConfig.dev` | 282 282 - | User packages | `home.packages` | `home.packages` | 283 283 - | Programs | `programs.*` | `programs.*` | 284 284 - | System services | `services.*` | Not available | 285 285 - 286 286 - ### XDG Directories 287 287 - 288 288 - Home-manager manages XDG directories via `xdg.configFile`, `xdg.dataFile`, etc.: 289 289 - 290 290 - ```nix 291 291 - { config, ... }: 292 292 - { 293 293 - xdg.configFile."opencode/agents" = { 294 294 - source = ./agents; 295 295 - recursive = true; 296 296 - }; 297 297 - 298 298 - programs.opencode = { 299 299 - enable = true; 300 300 - package = opencodePkg; 301 301 - settings = { 302 302 - theme = "catppuccin-macchiato"; 303 303 - }; 304 304 - }; 305 305 - } 306 306 - ```

-35

modules/opencode/rules/typescript.md

··· 1 1 - ### TypeScript Best Practices 2 2 - 3 3 - #### Code Style 4 4 - - Use strict mode (`"strict": true` in tsconfig.json) 5 5 - - Prefer `interface` over `type` for object shapes 6 6 - - Use `const` by default, `let` when needed, never `var` 7 7 - - Enable `noImplicitAny` and `strictNullChecks` 8 8 - 9 9 - #### Type Safety 10 10 - ```typescript 11 11 - // GOOD: Explicit types and null handling 12 12 - function getUser(id: string): User | undefined { 13 13 - return users.get(id); 14 14 - } 15 15 - 16 16 - const user = getUser(id); 17 17 - if (user) { 18 18 - console.log(user.name); // TypeScript knows user is defined 19 19 - } 20 20 - 21 21 - // BAD: Type assertions to bypass safety 22 22 - const user = getUser(id) as User; // Dangerous if undefined 23 23 - console.log(user.name); // Might crash 24 24 - ``` 25 25 - 26 26 - #### Error Handling 27 27 - - Use try/catch for async operations 28 28 - - Define custom error types for domain errors 29 29 - - Never swallow errors silently 30 30 - 31 31 - #### Security 32 32 - - Validate all user input at API boundaries 33 33 - - Use parameterized queries for database operations 34 34 - - Sanitize data before rendering in DOM (prevent XSS) 35 35 - - Never use `eval()` or `Function()` with user input