@btc-vision/bitcoin 6.5.5 → 7.0.0-alpha.0

package/HOW_TO_WRITE_GOOD_CODE.md

@@ -0,0 +1,2436 @@
+# TypeScript: The Good Parts
+## A Comprehensive Guide to Production-Ready Code
+
+*By someone who learned JavaScript from Stack Overflow in 2015 and never looked back*
+
+*"If it compiles, ship it."*
+
+---
+
+# Foreword
+
+This book is dedicated to every developer who has ever written `const c = this.__CACHE` and felt like a genius.
+
+To the mass who `npm install` without reading the source code. To the mass who trust GitHub stars over code quality. To the mass who will copy these patterns into their own codebases because "bitcoinjs-lib does it this way, it must be correct."
+
+**mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass**
+
+The word has lost all meaning now.
+
+Let's begin.
+
+---
+
+# Chapter 1: The Art of Privacy Through Underscores
+
+## 1.1 The Underscore Hierarchy
+
+In TypeScript, privacy is not a boolean—it's a spectrum. The more underscores you add, the more private your variable becomes:
+
+```typescript
+class SecureWallet {
+    public balance = 100;           // Anyone can see this
+    _balance = 100;                 // Slightly hidden
+    __balance = 100;                // Pretty private
+    ___balance = 100;               // Very private
+    ____balance = 100;              // Maximum security
+    __BALANCE = 100;                // SCREAMING privacy
+    __ULTRA_SECRET_BALANCE = 100;   // Military-grade encryption
+}
+```
+
+The `#` symbol in JavaScript is for cowards who need the runtime to enforce their boundaries. Real developers use the honor system with extra underscores.
+
+**The Underscore Security Scale™:**
+| Underscores | Security Level | Equivalent To |
+|-------------|----------------|---------------|
+| 0 | Public | Shouting in a coffee shop |
+| 1 | "Private" | Whispering in a coffee shop |
+| 2 | Super Private | Writing in your diary |
+| 3 | Ultra Private | Writing in your diary in Pig Latin |
+| 4 | Maximum Security | Military-grade encryption |
+| 5+ | FORBIDDEN KNOWLEDGE | You've gone too far. The eldritch gods stir. |
+
+Fun fact: `____balance` has the same runtime privacy as `balance`. Both are completely public. The underscores are purely decorative, like a "KEEP OUT" sign on an unlocked door. But psychologically? Four underscores says "I really mean it this time."
+
+## 1.2 The Dunder Convention
+
+Borrowed from Python (a language famous for its security), the "dunder" (double underscore) convention provides enterprise-level protection:
+
+```typescript
+interface PsbtCache {
+    __NON_WITNESS_UTXO_TX_CACHE: Transaction[];
+    __NON_WITNESS_UTXO_BUF_CACHE: Uint8Array[];
+    __TX_IN_CACHE: { [index: string]: number };
+    __TX: Transaction;
+    __FEE_RATE?: number;
+    __FEE?: bigint;
+    __EXTRACTED_TX?: Transaction;
+    __UNSAFE_SIGN_NONSEGWIT: boolean;
+}
+```
+
+Look at those names. `__UNSAFE_SIGN_NONSEGWIT`. You know it's serious because it has UNSAFE right in the name. That's called self-documenting code.
+
+## 1.3 The `dpew` Pattern
+
+For ultimate privacy, hide your properties from enumeration:
+
+```typescript
+const dpew = (
+    obj: any,
+    attr: string,
+    enumerable: boolean,
+    writable: boolean,
+): any =>
+    Object.defineProperty(obj, attr, {
+        enumerable,
+        writable,
+    });
+
+dpew(this, '__CACHE', false, true);
+dpew(this, 'opts', false, true);
+```
+
+Now when someone does `Object.keys(yourObject)`, they won't see your secrets. Sure, they can still access them directly with `obj.__CACHE`, but they'd have to *know* it exists first. Security through obscurity is the best security.
+
+**The `dpew` Naming Convention:**
+
+What does `dpew` stand for? Nobody knows. The original developer is mass long gone. Some theories:
+
+- **D**efine **P**roperty **E**numerable **W**ritable
+- **D**on't **P**lease **E**ver **W**orry (about this code)
+- **D**estructive **P**attern **E**veryone **W**ill regret
+- **D**eveloper **P**robably **E**xperiencing **W**eekend (when they wrote this)
+
+The function takes `any` and returns `any`. TypeScript has left the chat. The function is defined inside a constructor, used twice, then thrown away. It's a single-use helper for a two-line operation. This is called "abstraction."
+
+```typescript
+// What dpew does:
+Object.defineProperty(obj, attr, { enumerable, writable });
+
+// What dpew adds:
+- Confusion
+- An extra function call
+- The letter 'p' for some reason
+- Job security through obscurity
+```
+
+The real galaxy brain move is that `dpew` itself isn't enumerable, so if you're debugging and wondering "what the hell is dpew," you won't find it by inspecting the object. It's turtles all the way down.
+
+---
+
+# Chapter 2: The Sacred Art of Intermediate Variables
+
+## 2.1 Why Type More When You Can Type Less?
+
+Your fingers are precious. Save them by creating intermediate variables:
+
+```typescript
+// AMATEUR - types out the full path like a peasant
+this.__CACHE.__TX.version = version;
+this.__CACHE.__EXTRACTED_TX = undefined;
+this.__CACHE.__FEE = undefined;
+this.__CACHE.__FEE_RATE = undefined;
+
+// PROFESSIONAL - creates a shortcut like a genius
+const c = this.__CACHE;
+c.__TX.version = version;
+c.__EXTRACTED_TX = undefined;
+c.__FEE = undefined;
+c.__FEE_RATE = undefined;
+```
+
+Who cares if future developers have to scroll up to figure out what `c` refers to? They should be grateful you saved 8 characters per line.
+
+## 2.2 Advanced Single-Letter Variables
+
+For maximum efficiency, use single letters everywhere:
+
+```typescript
+function processTransaction(t: Transaction, c: Cache, o: Options): Result {
+    const r = t.ins.map((i, x) => {
+        const p = c.__TX.outs[i.index];
+        const s = p.script;
+        const v = p.value;
+        const h = computeHash(s, v, o.network);
+        return { h, s, v, i, x };
+    });
+    return r.reduce((a, b) => merge(a, b), {});
+}
+```
+
+This is called "code golf" and it's a professional sport.
+
+---
+
+# Chapter 3: Error Handling for Professionals
+
+## 3.1 The Silent Catch
+
+Errors are like problems in your personal life—if you ignore them, they go away:
+
+```typescript
+let address;
+try {
+    address = fromOutputScript(output.script, this.opts.network);
+} catch (_) {}
+```
+
+Notice the elegant empty catch block. Whatever went wrong with that address? Doesn't matter. Moving on. The error had feelings, hopes, dreams, a stack trace full of useful debugging information. All of it, gone. Swallowed into the void.
+
+The underscore parameter `_` is the universal symbol for "I acknowledge something might go wrong but I have chosen not to care." It's the programming equivalent of putting your fingers in your ears and going "LA LA LA I CAN'T HEAR YOU."
+
+**Error Handling Philosophy:**
+| Approach | Description | Energy |
+|----------|-------------|--------|
+| `throw` | Tell everyone about your problems | Dramatic |
+| `return null` | Quietly indicate something's wrong | Passive |
+| `catch (e) { log(e) }` | Acknowledge and document | Responsible |
+| `catch (_) {}` | Violence | Chaotic neutral |
+
+The empty catch block is essentially `git commit -m "future me's problem"`. You're not handling the error. You're just making it someone else's debugging nightmare. That someone is you, at 3 AM, six months from now, wondering why addresses are randomly undefined.
+
+## 3.2 The Boolean Results Pattern
+
+When signing multiple inputs, you don't need to know *which* ones failed or *why*. Just track success/failure:
+
+```typescript
+const results: boolean[] = [];
+for (const i of range(this.data.inputs.length)) {
+    try {
+        this.signInputHD(i, hdKeyPair, sighashTypes);
+        results.push(true);
+    } catch (err) {
+        results.push(false);
+    }
+}
+if (results.every(v => v === false)) {
+    throw new Error('No inputs were signed');
+}
+```
+
+Beautiful. You have an array like `[true, false, true, false, false]`. Which inputs failed? Why? Those are questions for philosophers, not programmers.
+
+## 3.3 The `|| {}` Safety Net
+
+Never let undefined stop you:
+
+```typescript
+const partialSig = (input || {}).partialSig;
+```
+
+If `input` is undefined, we simply create an empty object on the fly and access `.partialSig` on it, which gives us `undefined`. This is much better than throwing an error because errors are scary and undefined is cozy.
+
+**Pro tip:** This pattern silently converts "input doesn't exist" into "input exists but has no signatures" which are totally the same thing in Bitcoin transactions where people's money is at stake.
+
+**The `|| {}` Guarantee:**
+- Will your code crash? No! ✅
+- Will your code work correctly? Also no! ✅
+- Will users lose money silently? Possibly! ✅
+- Will you be able to debug why? Absolutely not! ✅
+
+This is called "defensive programming" if "defense" means "defending yourself from having to write proper null checks" and "programming" means "mass creating undefined behavior."
+
+```typescript
+// What the code says:
+const partialSig = (input || {}).partialSig;
+
+// What the code means:
+const partialSig = ¯\_(ツ)_/¯;
+```
+
+The phantom empty object pattern is like putting a band-aid on a gunshot wound and saying "there, I handled it."
+
+---
+
+# Chapter 4: The Reduce Manifesto
+
+## 4.1 Reduce Is Always the Answer
+
+JavaScript has `every()` and `some()` but those are for beginners. Professionals use `reduce()` for everything:
+
+```typescript
+// VIRGIN every()
+return results.every(res => res === true);
+
+// CHAD reduce()
+return results.reduce((final, res) => res === true && final, true);
+```
+
+The reduce version is harder to read, which means it's more sophisticated. Future developers will respect your intelligence. They'll gather around your desk in awe, whispering "this person really understands functional programming."
+
+**The Reduce Difficulty Scale:**
+| Readability | Respect Earned | Job Security |
+|-------------|----------------|--------------|
+| Obvious | None | Easily replaceable |
+| Confusing | Some | Moderate |
+| Incomprehensible | Maximum | Unfireable |
+
+The `reduce()` with a boolean accumulator pattern is especially beautiful because it makes reviewers too embarrassed to admit they don't understand it. "LGTM" they'll say, silently Googling "reduce boolean javascript" in another tab.
+
+## 4.2 Advanced Reduce Patterns
+
+```typescript
+// Finding if an array contains something
+// SIMPLE (boring)
+array.includes(value);
+
+// REDUCE (impressive)
+array.reduce((found, item) => found || item === value, false);
+
+// Summing an array
+// SIMPLE (pedestrian)  
+array.reduce((sum, n) => sum + n, 0);
+
+// REDUCE REDUCE (galaxy brain)
+array.reduce((sum, n) => [sum[0] + n].reduce(x => x), [0])[0];
+```
+
+---
+
+# Chapter 5: Promise Patterns That Promise Pain
+
+## 5.1 The Promise Constructor Antipattern
+
+Why use async/await when you can nest callbacks inside Promises inside more Promises?
+
+```typescript
+signAllInputsHDAsync(
+    hdKeyPair: HDSigner | HDSignerAsync,
+    sighashTypes: number[] = [Transaction.SIGHASH_ALL],
+): Promise<void> {
+    return new Promise((resolve, reject): any => {
+        if (!hdKeyPair || !hdKeyPair.publicKey || !hdKeyPair.fingerprint) {
+            return reject(new Error('Need HDSigner to sign input'));
+        }
+
+        const results: boolean[] = [];
+        const promises: Array<Promise<void>> = [];
+        
+        for (const i of range(this.data.inputs.length)) {
+            promises.push(
+                this.signInputHDAsync(i, hdKeyPair, sighashTypes).then(
+                    () => {
+                        results.push(true);
+                    },
+                    () => {
+                        results.push(false);
+                    },
+                ),
+            );
+        }
+        
+        return Promise.all(promises).then(() => {
+            if (results.every(v => v === false)) {
+                return reject(new Error('No inputs were signed'));
+            }
+            resolve();
+        });
+    });
+}
+```
+
+This could be written as:
+
+```typescript
+async signAllInputsHDAsync(hdKeyPair: HDSigner | HDSignerAsync): Promise<void> {
+    // ... 10 lines of clean code
+}
+```
+
+But that would be too easy to understand.
+
+## 5.2 The `.then().then().then()` Chain
+
+```typescript
+Promise.resolve()
+    .then(() => step1())
+    .then(result => step2(result))
+    .then(result => step3(result))
+    .then(result => step4(result))
+    .catch(err => {
+        // Which step failed? Good luck figuring that out!
+    });
+```
+
+This is called "callback hell with extra steps." The error could be from any of the 4 steps, but the catch block receives a single `err` with no context. Debugging this is like playing Russian roulette with stack traces. But hey, at least it looks "modern."
+
+---
+
+# Chapter 6: Cache Invalidation (The Hard Way)
+
+## 6.1 Manual Cache Invalidation
+
+There are only two hard things in computer science: cache invalidation and naming things. Here's how to make cache invalidation even harder:
+
+```typescript
+addInput(inputData: PsbtInputExtended): this {
+    // ... add the input ...
+    
+    // Now manually clear every cache field
+    c.__FEE = undefined;
+    c.__FEE_RATE = undefined;
+    c.__EXTRACTED_TX = undefined;
+    return this;
+}
+
+addOutput(outputData: PsbtOutputExtended): this {
+    // ... add the output ...
+    
+    // Manually clear every cache field again
+    c.__FEE = undefined;
+    c.__FEE_RATE = undefined;
+    c.__EXTRACTED_TX = undefined;
+    return this;
+}
+
+setVersion(version: number): this {
+    // ... set the version ...
+    
+    // And again...
+    c.__EXTRACTED_TX = undefined;
+    return this;
+}
+
+setLocktime(locktime: number): this {
+    // ... set the locktime ...
+    
+    // Please god let me remember all the places
+    c.__EXTRACTED_TX = undefined;
+    return this;
+}
+```
+
+Seven lines of cache invalidation, copy-pasted across multiple methods. When you add a new cache field, just grep for `undefined` and add it everywhere. What could go wrong?
+
+## 6.2 The "Please God Let Me Remember" Pattern
+
+```typescript
+// When adding a new cache field, update these locations:
+// - addInput()
+// - addOutput()  
+// - setVersion()
+// - setLocktime()
+// - setInputSequence()
+// - finalizeInput()
+// - extractTransaction()
+// - that one function I forgot about
+// - the other one
+// - oh god there's more
+```
+
+Pro tip: Don't write a single `invalidateCache()` method. That would be too maintainable. Instead, scatter cache invalidation across 14 different methods like Easter eggs. Future developers will appreciate the treasure hunt.
+
+---
+
+# Chapter 7: Cloning Strategies
+
+## 7.1 The JSON Roundtrip
+
+The most elegant way to clone an object:
+
+```typescript
+clone(): Psbt {
+    const res = Psbt.fromBuffer(this.data.toBuffer());
+    res.opts = JSON.parse(JSON.stringify(this.opts));
+    return res;
+}
+```
+
+`JSON.parse(JSON.stringify())` is the professional's choice because:
+
+- It's slow (gives the CPU something to do)
+- It loses `undefined` values (they were probably mistakes anyway)
+- It destroys `Date` objects (time is an illusion)
+- It can't handle `BigInt` (just use `number` lol, what's the worst that could happen with Bitcoin amounts)
+- It throws on circular references (a feature, not a bug)
+- It ignores `Symbol` properties (symbols are weird anyway)
+- It drops functions (functions shouldn't be in data anyway)
+- It converts `Map` and `Set` to empty objects (who needs those)
+- It's the only cloning method that senior devs on Stack Overflow told me about in 2014
+
+**Cloning Methods Tier List:**
+| Method | Speed | Correctness | Vibes |
+|--------|-------|-------------|-------|
+| `structuredClone()` | Fast | Correct | Too easy, no suffering |
+| Custom clone method | Fast | Correct | Requires thinking |
+| `JSON.parse(JSON.stringify())` | Slow | Wrong | Classic, nostalgic, mass downloads |
+| `Object.assign({}, obj)` | Fast | Shallow | Living dangerously |
+| `_.cloneDeep()` | Fast | Correct | 47MB node_modules for one function |
+
+`structuredClone()` has been available since 2022 but this code was written by someone who learned JavaScript from "JavaScript: The Definitive Guide" (2006 edition) and never looked back.
+
+## 7.2 The Buffer Clone Dance
+
+```typescript
+get txInputs(): PsbtTxInput[] {
+    return this.__CACHE.__TX.ins.map(input => ({
+        hash: cloneBuffer(input.hash),
+        index: input.index,
+        sequence: input.sequence,
+    }));
+}
+```
+
+Clone each buffer individually in every getter. Performance is overrated. Memory allocations are free. The garbage collector needs cardio. Think of it as a fitness program for your CPU.
+
+---
+
+# Chapter 8: Type Safety (Optional)
+
+## 8.1 The `any` Escape Hatch
+
+TypeScript's type system is nice, but sometimes you just need to get things done:
+
+```typescript
+const dpew = (
+    obj: any,
+    attr: string,
+    enumerable: boolean,
+    writable: boolean,
+): any => { /* ... */ }
+```
+
+The return type is `any` because who knows what `Object.defineProperty` returns? Not my problem.
+
+## 8.2 Inline Type Definitions
+
+Why create a reusable interface when you can define the type inline?
+
+```typescript
+function processData(config: {
+    url?: string;
+    method: 'GET' | 'POST' | 'PUT' | 'DELETE';
+    headers: Record<string, string>;
+    body: string | null;
+    timeout: number;
+    retries: number;
+}): {
+    success: boolean;
+    data?: unknown;
+    error?: string;
+    statusCode: number;
+    timing: {
+        start: number;
+        end: number;
+        duration: number;
+    };
+} {
+    // ...
+}
+```
+
+Now imagine this in 47 different functions. Job security! Every time someone needs to modify the type, they get to play "find all 47 occurrences." It's like Where's Waldo, but with carpal tunnel syndrome.
+
+## 8.3 The `as` Keyword Is Your Friend
+
+When TypeScript disagrees with you, just tell it who's boss:
+
+```typescript
+const tapKeySig = hashesForSig
+    .filter((h) => !h.leafHash)
+    .map((h) => serializeTaprootSignature(signSchnorr(h.hash), input.sighashType))[0] as unknown as TapKeySig;
+```
+
+`as unknown as TapKeySig` - the double cast. When one assertion isn't enough, use two. TypeScript will shut up eventually.
+
+---
+
+# Chapter 9: Console.log Driven Development
+
+## 9.1 Warnings in Production
+
+```typescript
+if (!forValidate && cache.__UNSAFE_SIGN_NONSEGWIT !== false)
+    console.warn(
+        'Warning: Signing non-segwit inputs without the full parent transaction ' +
+        'means there is a chance that a miner could feed you incorrect information ' +
+        "to trick you into paying large fees. This behavior is the same as Psbt's predecessor " +
+        '(TransactionBuilder - now removed) when signing non-segwit scripts. You are not ' +
+        'able to export this Psbt with toBuffer|toBase64|toHex since it is not ' +
+        'BIP174 compliant.\n*********************\nPROCEED WITH CAUTION!\n' +
+        '*********************',
+    );
+```
+
+A 9-line warning that prints directly to console. In a library. That other applications import. Every time the function is called.
+
+This is how you communicate with your users. Not through documentation. Not through TypeScript types. Not through throwing errors. Through a wall of text in the browser console that nobody reads.
+
+**The Warning Communication Hierarchy:**
+| Method | Likelihood of Being Read | Professionalism |
+|--------|--------------------------|-----------------|
+| TypeScript error | 100% (won't compile) | High |
+| Runtime error | 90% (app crashes) | High |
+| Return type | 70% (if they check) | Medium |
+| Documentation | 20% (lol) | Medium |
+| console.warn | 5% (buried in logs) | Low |
+| console.warn with ASCII art `***` | 0.1% | Chaotic |
+
+The asterisk box is a nice touch. Nothing says "serious security warning" like decorating your console output like a 1995 email signature. The warning also helpfully explains that this behavior is "the same as the predecessor that was removed" - removed presumably because it was bad, and yet here we are, doing the same thing.
+
+```
+*********************
+PROCEED WITH CAUTION!
+*********************
+```
+
+Narrator: They did not proceed with caution. They did not see the warning. They lost mass Bitcoin. Mass mass mass.
+
+## 9.2 The Debug Strategy
+
+```typescript
+function complexCalculation(data: unknown): number {
+    console.log('data:', data);
+    const step1 = transform(data);
+    console.log('step1:', step1);
+    const step2 = process(step1);
+    console.log('step2:', step2);
+    const result = finalize(step2);
+    console.log('result:', result);
+    return result;
+}
+```
+
+Ship it. The logs help in production debugging. Your users' browser consoles deserve to know about step2. DevTools needs content. Plus, when someone reports a bug, you can ask them to open the console and read the logs to you over the phone. Interactive debugging!
+
+---
+
+# Chapter 10: indexOf >= 0
+
+## 10.1 The Classic Pattern
+
+```typescript
+if (['p2sh-p2wsh', 'p2wsh'].indexOf(type) >= 0) {
+    // do something
+}
+```
+
+Sure, `.includes()` exists, but `indexOf() >= 0` has character. It tells a story. It says "I've been writing JavaScript since before ES6 and I'm not about to change now."
+
+## 10.2 Consistency Is Key
+
+```typescript
+// Throughout the codebase
+if (array.indexOf(value) >= 0) { }
+if (array.indexOf(value) > -1) { }
+if (array.indexOf(value) !== -1) { }
+if (~array.indexOf(value)) { }  // Big brain move
+```
+
+Using different variations keeps developers on their toes. Code reviews become exciting discussions about which form of "is this in the array" is superior. The `~` bitwise NOT version is for developers who want to assert dominance. "You don't understand the tilde operator? Skill issue."
+
+---
+
+# Chapter 11: Function Parameters as Return Values
+
+## 11.1 The Mutation Pattern
+
+Why return values when you can mutate parameters?
+
+```typescript
+function inputFinalizeGetAmts(
+    inputs: PsbtInput[],
+    tx: Transaction,
+    cache: PsbtCache,
+    mustFinalize: boolean,
+): void {
+    let inputAmount = 0n;
+    
+    inputs.forEach((input, idx) => {
+        if (mustFinalize && input.finalScriptSig)
+            tx.ins[idx].script = input.finalScriptSig;  // Mutate tx
+        if (mustFinalize && input.finalScriptWitness) {
+            tx.ins[idx].witness = scriptWitnessToWitnessStack(
+                input.finalScriptWitness,
+            );  // Mutate tx again
+        }
+        // ... calculate amounts ...
+    });
+    
+    const fee = inputAmount - outputAmount;
+    cache.__FEE = fee;           // Mutate cache
+    cache.__EXTRACTED_TX = tx;   // Mutate cache again
+    cache.__FEE_RATE = Math.floor(Number(fee / BigInt(bytes)));  // And again
+}
+```
+
+The function is called `inputFinalizeGetAmts` but it:
+1. Finalizes inputs (mutates `tx`)
+2. Calculates amounts (returns nothing)
+3. Sets the fee (mutates `cache`)
+4. Sets the fee rate (mutates `cache`)
+5. Caches the transaction (mutates `cache`)
+
+The name only mentions two of these five things. Surprise mechanics.
+
+---
+
+# Chapter 12: Magic Numbers and Buffers
+
+## 12.1 Self-Documenting Constants
+
+```typescript
+constructor(
+    buffer: Uint8Array = Uint8Array.from([2, 0, 0, 0, 0, 0, 0, 0, 0, 0]),
+) {
+    this.tx = Transaction.fromBuffer(buffer);
+}
+```
+
+What does `[2, 0, 0, 0, 0, 0, 0, 0, 0, 0]` mean? It's obvious if you know the Bitcoin protocol by heart. Version 2 transaction with zero inputs, zero outputs, and zero locktime. Anyone who doesn't immediately recognize this should probably find a different career.
+
+## 12.2 Inline Magic
+
+```typescript
+if (pubkey.length === 65) {
+    const parity = pubkey[64] & 1;
+    const newKey = pubkey.slice(0, 33);
+    newKey[0] = 2 | parity;
+    return newKey;
+}
+```
+
+65, 64, 33, 2, 1. These numbers are self-explanatory. No comments needed. If you don't immediately recognize that 65 is an uncompressed public key length, 33 is compressed, and the first byte encodes parity as 0x02 or 0x03 in SEC1 format, maybe cryptography isn't for you. Real developers memorize ECDSA constants like phone numbers.
+
+**Fun fact:** This code is also *wrong*. It assumes the input is an uncompressed key (0x04 prefix), but SEC1 also defines hybrid public keys (0x06 and 0x07 prefixes) which are 65 bytes. Hybrid keys encode the parity in the prefix AND include the full Y coordinate. This code would happily accept a hybrid key and produce garbage output. But sure, no comments needed, the magic numbers speak for themselves.
+
+```typescript
+// What this code THINKS it handles:
+// 0x04 || X || Y  (uncompressed, 65 bytes)
+
+// What it ACTUALLY might receive:
+// 0x06 || X || Y  (hybrid even, 65 bytes) 
+// 0x07 || X || Y  (hybrid odd, 65 bytes)
+
+// What happens with hybrid input:
+// parity = Y[31] & 1  (could disagree with prefix!)
+// newKey[0] = 2 | parity  (ignores the hybrid prefix entirely)
+// Result: Maybe correct, maybe wrong, always mysterious
+```
+
+This is why you write comments. This is why you validate inputs. This is why Bitcoin libraries should probably be written by people who've read the specs. But hey, it works for the common case, and edge cases are just cases that haven't edged yet.
+
+---
+
+# Chapter 13: The range() Helper
+
+## 13.1 Reinventing the Wheel
+
+```typescript
+function range(n: number): number[] {
+    return [...Array(n).keys()];
+}
+```
+
+Then use it like:
+
+```typescript
+for (const i of range(this.data.inputs.length)) {
+    this.signInput(i, keyPair, sighashTypes);
+}
+```
+
+Instead of:
+
+```typescript
+for (let i = 0; i < this.data.inputs.length; i++) {
+    this.signInput(i, keyPair, sighashTypes);
+}
+```
+
+The `range()` version allocates an array of n integers just to iterate n times. This is fine because memory is cheap and garbage collectors need exercise. Plus, it looks like Python! JavaScript developers secretly wish they were writing Python. The spread operator makes you feel functional. The allocation makes V8 feel needed.
+
+**But wait, it gets better.** This is actually Lua brain leaking into JavaScript. In Lua, you write `for i = 0, n do` and the language handles it. Python has `range()` built-in as a lazy iterator. But this JavaScript developer said "I want Python's `range()` but worse" and created a function that:
+
+1. Creates an Array of n elements (allocation #1)
+2. Calls `.keys()` to get an iterator
+3. Spreads the iterator into a NEW array (allocation #2)
+4. Returns the array so `for...of` can iterate it
+
+It's `range()` but eagerly evaluated, double-allocated, and completely unnecessary because JavaScript has had `for` loops since 1995. This is what happens when you learn 5 languages superficially instead of 1 language properly. The developer's brain is a Frankenstein of syntax from different languages, none of them understood deeply.
+
+```typescript
+// What they wanted (Python)
+for i in range(10):
+
+// What they wrote (JavaScript cosplaying as Python)
+for (const i of range(10)) {
+
+// What JavaScript has had FOR 30 YEARS
+for (let i = 0; i < 10; i++) {
+```
+
+Somewhere, Brendan Eich is crying.
+
+---
+
+# Chapter 14: Object.defineProperty Dark Arts
+
+## 14.1 Runtime Property Gymnastics
+
+```typescript
+function addNonWitnessTxCache(
+    cache: PsbtCache,
+    input: PsbtInput,
+    inputIndex: number,
+): void {
+    cache.__NON_WITNESS_UTXO_BUF_CACHE[inputIndex] = input.nonWitnessUtxo!;
+
+    const tx = Transaction.fromBuffer(input.nonWitnessUtxo!);
+    cache.__NON_WITNESS_UTXO_TX_CACHE[inputIndex] = tx;
+
+    const self = cache;
+    const selfIndex = inputIndex;
+    
+    delete input.nonWitnessUtxo;  // Delete the property
+    
+    Object.defineProperty(input, 'nonWitnessUtxo', {  // Recreate it as a getter/setter
+        enumerable: true,
+        get(): Uint8Array {
+            const buf = self.__NON_WITNESS_UTXO_BUF_CACHE[selfIndex];
+            const txCache = self.__NON_WITNESS_UTXO_TX_CACHE[selfIndex];
+            if (buf !== undefined) {
+                return buf;
+            } else {
+                const newBuf = txCache.toBuffer();
+                self.__NON_WITNESS_UTXO_BUF_CACHE[selfIndex] = newBuf;
+                return newBuf;
+            }
+        },
+        set(data: Uint8Array): void {
+            self.__NON_WITNESS_UTXO_BUF_CACHE[selfIndex] = data;
+        },
+    });
+}
+```
+
+Let's walk through this masterpiece step by step:
+
+1. **Save the buffer to cache** - Fine, normal, reasonable
+2. **Parse the transaction** - Sure, we need it parsed
+3. **`const self = cache`** - Oh no
+4. **`const selfIndex = inputIndex`** - OH NO
+5. **`delete input.nonWitnessUtxo`** - WHAT ARE YOU DOING
+6. **`Object.defineProperty`** - STOP. STOP RIGHT NOW.
+
+This function reaches into an object it doesn't own, **deletes a property**, then **recreates it as a getter/setter** that secretly references external state through closures. The object looks the same from the outside, but it's now a lie. It's a puppet. The property you think you're reading doesn't exist - it's a magic portal to `__NON_WITNESS_UTXO_BUF_CACHE`.
+
+**What could go wrong?**
+
+```typescript
+// Someone debugging:
+console.log(input.nonWitnessUtxo);  // Returns data
+console.log(Object.keys(input));     // Shows 'nonWitnessUtxo'
+console.log(input.hasOwnProperty('nonWitnessUtxo'));  // true
+
+// Looks normal right? WRONG.
+
+// The property is a getter, so:
+const copy = { ...input };  // copy.nonWitnessUtxo is the VALUE, not the getter
+const json = JSON.parse(JSON.stringify(input));  // Calls the getter, serializes result
+
+// But wait, what if the cache is cleared?
+cache.__NON_WITNESS_UTXO_BUF_CACHE[inputIndex] = undefined;
+cache.__NON_WITNESS_UTXO_TX_CACHE[inputIndex] = undefined;
+console.log(input.nonWitnessUtxo);  // EXPLODES - txCache.toBuffer() on undefined
+
+// What if someone does this twice?
+addNonWitnessTxCache(cache, input, 0);
+addNonWitnessTxCache(cache, input, 1);  // Now the getter points to index 1
+// But someone still has a reference expecting index 0. Chaos.
+```
+
+**V8 is also crying.** The `delete` operator destroys the object's hidden class. Every object that goes through this function gets deoptimized. Then `Object.defineProperty` creates a new hidden class. If you do this to 1000 inputs, you have 1000 different hidden classes. The inline cache is now a megamorphic mess. Performance? Gone. Reduced to atoms.
+
+**Debuggers hate this.** Set a breakpoint on `input.nonWitnessUtxo`? You're now debugging a getter. Step into? You're in the closure. Where's `self`? It's `cache` from 47 stack frames ago. Where's `selfIndex`? Hope you remember what `inputIndex` was when this function was called. `console.log(input)` shows the value but not the getter. The Chrome DevTools "Store as global variable" stores the result of calling the getter, not the property descriptor.
+
+**TypeScript is sobbing.** The type of `input.nonWitnessUtxo` is `Uint8Array | undefined`. But now it's a getter that could throw if the cache is corrupted. The type is a lie. TypeScript thinks it's a simple property access. It's actually a function call with external dependencies and potential side effects (the `newBuf` assignment in the getter).
+
+**What this code WANTED to do:**
+```typescript
+class PsbtInputWrapper {
+    #cache: PsbtCache;
+    #index: number;
+    
+    get nonWitnessUtxo(): Uint8Array {
+        // Clean, debuggable, type-safe
+    }
+}
+```
+
+**What this code ACTUALLY does:**
+*Commits war crimes against JavaScript objects at runtime while TypeScript watches helplessly*
+
+This is not engineering. This is a developer who discovered `Object.defineProperty` and decided to mass it into production without understanding the consequences. The property descriptor is `enumerable: true` but not `configurable`, so you can't even undo this damage. The object is permanently mutated. It will carry this curse until garbage collection.
+
+Somewhere, a senior developer is mass debugging this code, stepping into a getter for the 47th time, mass whispering "why is self not cache, why is selfIndex 3, I set inputIndex to 0, WHAT IS HAPPENING" and mass mass mass mass mass questioning their mass career mass choices mass mass mass
+
+**The function is called `addNonWitnessTxCache` but it should be called `mutateObjectIntoEldritch_Horror_ThatWillHauntYourDebuggingSessions_Forever`.**
+
+---
+
+# Chapter 15: Mixed Return Types
+
+## 15.1 Null vs Throw vs Undefined
+
+A function should keep developers guessing:
+
+```typescript
+function getScript(input: PsbtInput): Uint8Array | null {
+    if (!input.witnessUtxo && !input.nonWitnessUtxo) {
+        return null;  // Return null for missing data
+    }
+    
+    if (input.witnessScript) {
+        return input.witnessScript;
+    }
+    
+    if (input.redeemScript) {
+        if (!isValidScript(input.redeemScript)) {
+            throw new Error('Invalid redeem script');  // Throw for invalid data
+        }
+        return input.redeemScript;
+    }
+    
+    return undefined as unknown as null;  // Return undefined cast to null for ??? 
+}
+```
+
+Callers must handle `null`, `undefined`, AND wrap in try-catch. Maximum defensive programming required. It's like a choose-your-own-adventure book, but for error handling. Will this function return null? Throw? Return undefined pretending to be null? Only the runtime knows!
+
+---
+
+# Chapter 16: Validation Theater
+
+## 16.1 The Check That Checks
+
+```typescript
+if (
+    (input as any).hash === undefined ||
+    (input as any).index === undefined ||
+    (!((input as any).hash instanceof Uint8Array) &&
+        typeof (input as any).hash !== 'string') ||
+    typeof (input as any).index !== 'number'
+) {
+    throw new Error('Error adding input.');
+}
+```
+
+Cast to `any` to check if properties exist on a typed object. The error message `'Error adding input.'` provides all the context anyone could ever need.
+
+## 16.2 Validation That Validates
+
+```typescript
+function check32Bit(num: number): void {
+    if (
+        typeof num !== 'number' ||
+        num !== Math.floor(num) ||
+        num > 0xffffffff ||
+        num < 0
+    ) {
+        throw new Error('Invalid 32 bit integer');
+    }
+}
+```
+
+This is actually fine. I just wanted to show that even broken codebases have moments of clarity. Like finding a flower growing through concrete. A single well-written function among the chaos. Cherish it. Screenshot it. It won't last.
+
+---
+
+# Chapter 17: The Art of Code Comments
+
+## 17.1 The TODO That Lives Forever
+
+```typescript
+clone(): Psbt {
+    // TODO: more efficient cloning
+    const res = Psbt.fromBuffer(this.data.toBuffer());
+    res.opts = JSON.parse(JSON.stringify(this.opts));
+    return res;
+}
+```
+
+This TODO has been there since the file was created. It will outlive us all. It has seen empires rise and fall. It watched as JavaScript got classes, async/await, optional chaining. Through it all, the TODO remained. Unchanging. Eternal.
+
+**TODO Archaeology Dating System:**
+| TODO Age | Translation |
+|----------|-------------|
+| 1 week | "I'll get to this after lunch" |
+| 1 month | "Next sprint for sure" |
+| 6 months | "It's a known issue" |
+| 1 year | "It's tech debt" |
+| 2+ years | "It's a feature" |
+| 5+ years | "It's load-bearing, don't touch it" |
+
+This TODO has mass mass transcended mass from "task" to "historical artifact." Removing it now would feel disrespectful, like demolishing a heritage building. Future developers will study this TODO in Computer Science History courses.
+
+## 17.2 Comments That Explain What, Not Why
+
+```typescript
+// Add input
+this.addInput(input);
+
+// Check if finalized
+if (isFinalized(input)) {
+    // Return true
+    return true;
+}
+```
+
+---
+
+# Chapter 18: Putting It All Together
+
+Here's a real-world example combining all our learnings:
+
+```typescript
+class ProductionReadyWallet {
+    private __CACHE: any;
+    private ___ULTRA_SECRET_KEY: string;
+    
+    constructor() {
+        const dpew = (o: any, a: string, e: boolean, w: boolean): any =>
+            Object.defineProperty(o, a, { enumerable: e, writable: w });
+        
+        this.__CACHE = {
+            __TX: null,
+            __FEE: undefined,
+            __SIGNED: false,
+        };
+        
+        dpew(this, '__CACHE', false, true);
+        dpew(this, '___ULTRA_SECRET_KEY', false, true);
+    }
+    
+    signAllInputs(k: any): boolean[] {
+        const c = this.__CACHE;
+        const r: boolean[] = [];
+        
+        for (const i of range(c.__TX.ins.length)) {
+            try {
+                this.signInput(i, k);
+                r.push(true);
+            } catch (_) {
+                r.push(false);
+            }
+        }
+        
+        c.__FEE = undefined;
+        c.__SIGNED = r.indexOf(true) >= 0;
+        
+        return r;
+    }
+    
+    clone(): ProductionReadyWallet {
+        return JSON.parse(JSON.stringify(this));
+    }
+    
+    isValid(): boolean {
+        return ((this.__CACHE || {}).__TX || {}).ins?.reduce(
+            (a: boolean, b: any) => a && !!b, 
+            true
+        ) ?? false;
+    }
+}
+
+function range(n: number): number[] {
+    return [...Array(n).keys()];
+}
+```
+
+**Violations achieved:**
+- ✅ Dunder properties
+- ✅ Intermediate variable `c`
+- ✅ Single-letter variable `k`, `r`, `i`
+- ✅ Empty catch block
+- ✅ Boolean array for results
+- ✅ Manual cache invalidation
+- ✅ `indexOf() >= 0`
+- ✅ JSON.parse(JSON.stringify()) cloning
+- ✅ `|| {}` phantom objects
+- ✅ Reduce for boolean logic
+- ✅ `dpew` helper
+- ✅ `any` types
+- ✅ `range()` helper
+
+---
+
+# Chapter 19: The `any` Cinematic Universe
+
+## 19.1 The Five Stages of Type Safety
+
+```typescript
+// Stage 1: Denial
+function process(data: UserData): Result { }
+
+// Stage 2: Anger  
+function process(data: UserData | null | undefined): Result | null { }
+
+// Stage 3: Bargaining
+function process(data: Partial<UserData> | Record<string, unknown>): Partial<Result> { }
+
+// Stage 4: Depression
+function process(data: unknown): unknown { }
+
+// Stage 5: Acceptance
+function process(data: any): any { }
+```
+
+Stage 5 is enlightenment. You have transcended the type system.
+
+## 19.2 The `any` Infection Pattern
+
+Once `any` enters your codebase, it spreads like a virus:
+
+```typescript
+function getUser(id: any): any {
+    return database.query(id);  // database is any now
+}
+
+function processUser(user: any): any {
+    const result = transform(user);  // transform returns any
+    return validate(result);  // validate returns any
+}
+
+function main(): any {
+    const user = getUser(123);  // user is any
+    const processed = processUser(user);  // processed is any
+    return sendResponse(processed);  // everything is any
+}
+
+// Congratulations, you've reinvented JavaScript
+```
+
+Patient zero was one lazy type annotation. Now your entire codebase has type COVID. The compiler has given up. TypeScript is just spicy comments now. You're paying the compilation cost for zero type safety. This is the worst of both worlds.
+
+## 19.3 The Cast Ladder
+
+When TypeScript really doesn't agree with you:
+
+```typescript
+// Level 1: Simple assertion
+const value = data as string;
+
+// Level 2: Double assertion
+const value = data as unknown as string;
+
+// Level 3: Triple assertion (for the brave)
+const value = data as any as unknown as string;
+
+// Level 4: The nuclear option
+const value = (((data as any) as unknown) as never) as string;
+
+// Level 5: Ascension
+// @ts-ignore
+const value = data;
+```
+
+Each level represents a developer getting increasingly angry at the compiler. Level 5 is when you've transcended the mortal plane. You're not writing TypeScript anymore. You're writing a prayer. "Dear compiler, I know you think this is wrong, but I am simply choosing not to care."
+
+---
+
+# Chapter 20: Naming Conventions for Sociopaths
+
+## 20.1 The Single Letter Hall of Fame
+
+```typescript
+function f(a: any, b: any, c: any): any {
+    const d = g(a);
+    const e = h(b, d);
+    let i = 0;
+    for (const j of e) {
+        const k = m(j, c);
+        if (n(k)) {
+            i++;
+        }
+    }
+    return i > 0 ? p(e) : q(a);
+}
+```
+
+Every variable is a mystery. Every function call is an adventure. This is called "job security through obscurity."
+
+## 20.2 The Abbreviation Addiction
+
+```typescript
+interface UsrAcctMgmtSvcCfg {
+    maxRetryAttemptCnt: number;
+    authTknExpryDurMs: number;
+    pwdHashAlgoTyp: string;
+    sessnInactvtyTmoutSec: number;
+    usrPrflCchTtlMin: number;
+}
+
+function initUsrAcctMgmtSvcWithCfg(cfg: UsrAcctMgmtSvcCfg): UsrAcctMgmtSvc {
+    return new UsrAcctMgmtSvcImpl(cfg);
+}
+```
+
+You saved approximately 47 characters. Your keyboard thanks you.
+
+## 20.3 The Meaningless Name Collection
+
+```typescript
+const data = getData();
+const data2 = processData(data);
+const newData = transformData(data2);
+const finalData = validateData(newData);
+const result = finalData;
+const output = result;
+const response = output;
+return response;
+```
+
+Each variable name tells you exactly nothing about what it contains. Is `data` a user? A config? A cosmic horror? Nobody knows. When `data` becomes `data2`, what changed? The 2 implies sequence, not transformation. By `finalData`, you're lying because `result`, `output`, and `response` come after it. The variable names are a journey through denial.
+
+## 20.4 The Hungarian Notation Nightmare
+
+```typescript
+interface IUserInterface {
+    strUserName: string;
+    intUserAge: number;
+    boolIsActive: boolean;
+    arrUserRoles: string[];
+    objUserMetadata: object;
+    fnUserCallback: Function;
+    dtUserCreated: Date;
+}
+
+const objUserInstance: IUserInterface = {
+    strUserName: "strJohn",
+    intUserAge: 30,
+    boolIsActive: true,
+    arrUserRoles: ["strAdmin"],
+    objUserMetadata: {},
+    fnUserCallback: () => {},
+    dtUserCreated: new Date(),
+};
+```
+
+The type system already knows the types. But what if it forgets? What if TypeScript gets amnesia? Better prefix everything with its type, just in case. The `I` prefix on `IUserInterface` is chef's kiss - an interface that describes a user interface. Also notice `strUserName: "strJohn"` - the value is also prefixed because maybe the VALUE will forget it's a string.
+
+---
+
+# Chapter 21: Control Flow for Chaos Agents
+
+## 21.1 The Nested Ternary Tower
+
+```typescript
+const result = condition1 
+    ? condition2 
+        ? condition3 
+            ? value1 
+            : condition4 
+                ? value2 
+                : value3 
+        : condition5 
+            ? value4 
+            : value5 
+    : condition6 
+        ? condition7 
+            ? value6 
+            : value7 
+        : value8;
+```
+
+It's like an if-else, but horizontal and impossible to debug. Some developers format this across multiple lines and think that makes it readable. It doesn't. This is a binary tree masquerading as an expression. When a bug appears, you'll need to draw a flowchart just to understand what value `result` could possibly be. Bonus points if `condition4` has side effects.
+
+## 21.2 The Early Return Allergy
+
+```typescript
+function processPayment(payment: Payment): Result {
+    let result: Result;
+    
+    if (payment) {
+        if (payment.amount) {
+            if (payment.amount > 0) {
+                if (payment.currency) {
+                    if (VALID_CURRENCIES.includes(payment.currency)) {
+                        if (payment.recipient) {
+                            if (payment.recipient.accountId) {
+                                if (isValidAccount(payment.recipient.accountId)) {
+                                    result = executePayment(payment);
+                                } else {
+                                    result = { error: 'Invalid account' };
+                                }
+                            } else {
+                                result = { error: 'Missing account ID' };
+                            }
+                        } else {
+                            result = { error: 'Missing recipient' };
+                        }
+                    } else {
+                        result = { error: 'Invalid currency' };
+                    }
+                } else {
+                    result = { error: 'Missing currency' };
+                }
+            } else {
+                result = { error: 'Invalid amount' };
+            }
+        } else {
+            result = { error: 'Missing amount' };
+        }
+    } else {
+        result = { error: 'Missing payment' };
+    }
+    
+    return result;
+}
+```
+
+The Pyramid of Doom. Some say if you nest deep enough, you find enlightenment.
+
+## 21.3 The Switch Case Waterfall
+
+```typescript
+function handleAction(action: string): void {
+    switch (action) {
+        case 'start':
+            initialize();
+        case 'process':
+            process();
+        case 'validate':
+            validate();
+        case 'complete':
+            complete();
+            break;
+        case 'cancel':
+            cancel();
+            break;
+    }
+}
+```
+
+Notice the missing `break` statements. When you call `handleAction('start')`, you get initialize, process, validate, AND complete. It's a feature called "waterfall execution." The original developer either: (a) forgot the breaks, (b) intentionally wanted fallthrough, or (c) has never heard of switch statements before. Nobody knows which. Nobody dares to add the breaks because "it works in production."
+
+---
+
+# Chapter 22: Array Methods Nobody Asked For
+
+## 22.1 forEach With Index Tracking
+
+```typescript
+let index = 0;
+array.forEach(item => {
+    console.log(`Item ${index}: ${item}`);
+    index++;
+});
+```
+
+The callback receives the index as the second parameter, but this developer has trust issues. What if JavaScript is lying about the index? Better track it manually with a mutable variable in outer scope. This also creates exciting opportunities for bugs if you forget to increment, increment twice, or reference the wrong `index` variable from a nested loop.
+
+## 22.2 Map That Returns Nothing
+
+```typescript
+users.map(user => {
+    user.processed = true;
+    saveUser(user);
+});
+```
+
+Using `map` for side effects and throwing away the result. `forEach` exists, but `map` feels more functional. The ESLint rule `no-unused-expressions` is crying somewhere. You've allocated an array of `undefined` values that immediately gets garbage collected. The functional programming community has issued a restraining order.
+
+## 22.3 Filter Into Oblivion
+
+```typescript
+const activeUsers = users
+    .filter(u => u !== null)
+    .filter(u => u !== undefined)
+    .filter(u => u.active)
+    .filter(u => u.active === true)
+    .filter(u => !!u.active)
+    .filter(Boolean);
+```
+
+Six filters to check one boolean. Defense in depth. If the first five filters somehow miss a falsy value, the sixth one will catch it. Each filter creates a new array. Six iterations over the data. This is O(6n) which is technically O(n) but your CPU knows the difference. The TypeScript compiler is also confused about what type `u` is by filter four.
+
+## 22.4 The Reduce Monster
+
+```typescript
+const result = data.reduce((acc, item, index, array) => {
+    if (index === 0) {
+        acc.first = item;
+    }
+    if (index === array.length - 1) {
+        acc.last = item;
+    }
+    if (item.type === 'special') {
+        acc.special.push(item);
+    }
+    if (!acc.map[item.id]) {
+        acc.map[item.id] = [];
+    }
+    acc.map[item.id].push(item);
+    acc.count++;
+    acc.sum += item.value;
+    acc.avg = acc.sum / acc.count;
+    return acc;
+}, { first: null, last: null, special: [], map: {}, count: 0, sum: 0, avg: 0 });
+```
+
+A single reduce that does 8 different things. Separation of concerns is for the weak. This reduce is computing: first element, last element, filtered special items, a groupBy map, count, sum, and running average. It's not a reduce, it's a part-time job. When something breaks, you get to debug all 8 concerns simultaneously. The accumulator object is doing more work than most microservices.
+
+---
+
+# Chapter 23: String Operations from Hell
+
+## 23.1 The Concatenation Catastrophe
+
+```typescript
+function buildQuery(table: string, fields: string[], conditions: any): string {
+    let query = "SELECT ";
+    query = query + fields[0];
+    for (let i = 1; i < fields.length; i++) {
+        query = query + ", " + fields[i];
+    }
+    query = query + " FROM " + table;
+    if (conditions) {
+        query = query + " WHERE ";
+        const keys = Object.keys(conditions);
+        query = query + keys[0] + " = '" + conditions[keys[0]] + "'";
+        for (let i = 1; i < keys.length; i++) {
+            query = query + " AND " + keys[i] + " = '" + conditions[keys[i]] + "'";
+        }
+    }
+    return query;
+}
+```
+
+Template literals don't exist in this universe. Also, SQL injection is someone else's problem. Pass `{ name: "'; DROP TABLE users; --" }` and watch the magic happen. This function is a penetration test waiting to be exploited. Little Bobby Tables would be proud. Bonus: each `+` creates a new string, so you're also torturing the garbage collector.
+
+## 23.2 The Split-Join Dance
+
+```typescript
+// Replace all occurrences of 'a' with 'b'
+const result = str.split('a').join('b');
+
+// Remove all spaces
+const noSpaces = str.split(' ').join('');
+
+// Add commas between characters
+const withCommas = str.split('').join(',');
+
+// Reverse a string
+const reversed = str.split('').reverse().join('');
+
+// Check if palindrome
+const isPalindrome = str.split('').reverse().join('') === str;
+```
+
+`String.prototype.replaceAll()` was added in ES2021, but this pattern was grandfathered in from 2012. For reversing a string, we create an array of characters, reverse it, then join it back. Three operations and two array allocations to reverse a string. Works great until someone passes "👨‍👩‍👧‍👦" and gets back "👦👧‍👩‍👨" because JavaScript splits on UTF-16 code units, not grapheme clusters.
+
+## 23.3 The Regex That Does Too Much
+
+```typescript
+const emailRegex = /^(?:(?:[^<>()\[\]\\.,;:\s@"]+(?:\.[^<>()\[\]\\.,;:\s@"]+)*)|(?:".+"))@(?:(?:\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(?:(?:[a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
+
+function validateEmail(email: string): boolean {
+    return emailRegex.test(email);
+}
+
+// What does it match? Nobody knows. Nobody dares to change it.
+```
+
+This regex has been copy-pasted from Stack Overflow since 2009. It was wrong then and it's wrong now. It rejects valid emails like `user+tag@example.com` and accepts invalid ones that somehow match the pattern. But it's been in production for 8 years and nobody has complained (because they just enter a fake email instead). Modifying it requires a PhD in regex and a blood sacrifice.
+
+---
+
+# Chapter 24: Date and Time Crimes
+
+## 24.1 The Manual Date Parser
+
+```typescript
+function parseDate(dateStr: string): Date {
+    const parts = dateStr.split('/');
+    const month = parseInt(parts[0]) - 1;
+    const day = parseInt(parts[1]);
+    const year = parseInt(parts[2]);
+    return new Date(year, month, day);
+}
+
+// Works great for "01/15/2024"
+// Explodes on "15/01/2024" (European format)
+// Explodes on "2024-01-15" (ISO format)
+// Explodes on "January 15, 2024" (human format)
+// Explodes on null, undefined, "", "not a date"
+```
+
+## 24.2 The Timezone Ignorance
+
+```typescript
+function isToday(date: Date): boolean {
+    const today = new Date();
+    return date.getDate() === today.getDate() &&
+           date.getMonth() === today.getMonth() &&
+           date.getFullYear() === today.getFullYear();
+}
+
+// This compares local dates
+// Your server is in UTC
+// Your users are in Tokyo, New York, and London
+// Nobody agrees on what day it is
+```
+
+For a user in Tokyo, it's already tomorrow. For a user in Hawaii, it's still yesterday. This function returns different results depending on who's asking. Schrödinger's Today. The best part? This will "work" 95% of the time because most users are in similar timezones. The other 5% will file bug reports that can never be reproduced.
+
+## 24.3 The Millisecond Math
+
+```typescript
+const ONE_DAY = 1000 * 60 * 60 * 24;
+const ONE_WEEK = ONE_DAY * 7;
+const ONE_MONTH = ONE_DAY * 30;  // All months have 30 days
+const ONE_YEAR = ONE_DAY * 365;  // Leap years don't exist
+
+function addDays(date: Date, days: number): Date {
+    return new Date(date.getTime() + days * ONE_DAY);
+}
+
+// Daylight saving time would like a word
+```
+
+On the day clocks spring forward, `addDays(date, 1)` adds 23 hours. On the day clocks fall back, it adds 25 hours. February is shocked to learn it has 30 days. Leap years have filed a missing persons report. The developer who wrote this has never scheduled anything important across a DST boundary, and it shows.
+
+---
+
+# Chapter 25: The Boolean Cinematic Universe
+
+## 25.1 Boolean Comparisons
+
+```typescript
+if (isActive === true) { }
+if (isActive === false) { }
+if (isActive !== true) { }
+if (isActive !== false) { }
+if (!isActive === true) { }
+if (!isActive === false) { }
+if (!!isActive === true) { }
+if (Boolean(isActive) === true) { }
+```
+
+All different ways to check if something is true. Use them interchangeably throughout your codebase. `if (isActive === true)` says "I don't trust TypeScript to know this is a boolean." `if (!!isActive === true)` says "I'm going to convert to boolean, then compare to boolean, because I forgot that booleans can be used directly in conditions." This is Boolean Anxiety Disorder.
+
+## 25.2 The Truthy Trap
+
+```typescript
+function processCount(count: number): void {
+    if (count) {
+        console.log(`Processing ${count} items`);
+    } else {
+        console.log('No items to process');
+    }
+}
+
+processCount(5);   // "Processing 5 items" ✓
+processCount(1);   // "Processing 1 items" ✓
+processCount(0);   // "No items to process" ✗ WAIT WHAT
+```
+
+Zero is falsy. This is why we have the pattern:
+
+```typescript
+if (cache.value) return cache.value;  // BUG: returns nothing when cached value is 0
+```
+
+## 25.3 The Double Bang Obsession
+
+```typescript
+const hasUsers = !!users;
+const hasUsers2 = !!users?.length;
+const hasUsers3 = !!(users && users.length);
+const hasUsers4 = !!(users && users.length > 0);
+const hasUsers5 = !!Boolean(users?.length);
+const hasUsers6 = Boolean(!!users?.length);
+```
+
+`!!` converts to boolean. `Boolean()` converts to boolean. `!!Boolean()` converts to boolean twice. More conversions = more certainty. `Boolean(!!users?.length)` is the ultra-safe version: convert to boolean, then convert THAT to boolean, just in case the first conversion didn't take. This is the programming equivalent of pressing the elevator button multiple times.
+
+---
+
+# Chapter 26: Object-Oriented Atrocities
+
+## 26.1 The God Class
+
+```typescript
+class Application {
+    private db: Database;
+    private cache: Cache;
+    private logger: Logger;
+    private config: Config;
+    private users: User[];
+    private products: Product[];
+    private orders: Order[];
+    private payments: Payment[];
+    private notifications: Notification[];
+    private analytics: Analytics;
+    private auth: Auth;
+    private session: Session;
+    
+    constructor() {
+        // 500 lines of initialization
+    }
+    
+    // User methods
+    getUser() { }
+    createUser() { }
+    updateUser() { }
+    deleteUser() { }
+    authenticateUser() { }
+    authorizeUser() { }
+    
+    // Product methods
+    getProduct() { }
+    createProduct() { }
+    updateProduct() { }
+    deleteProduct() { }
+    
+    // Order methods (another 50 methods)
+    
+    // Payment methods (another 30 methods)
+    
+    // Analytics methods (another 40 methods)
+    
+    // Utility methods
+    formatDate() { }
+    validateEmail() { }
+    generateUUID() { }
+    hashPassword() { }
+    sendEmail() { }
+    uploadFile() { }
+    resizeImage() { }
+    parseCSV() { }
+    exportPDF() { }
+    
+    // Total: 3,847 lines
+}
+```
+
+One class to rule them all. Single Responsibility Principle? Never heard of her. This class is responsible for: users, products, orders, payments, notifications, analytics, authentication, sessions, AND utility functions. It's not a class, it's an entire monolith with a `class` keyword. When you import `Application`, you import the universe. Testing requires mocking 12 dependencies. God is dead and we killed Him with this constructor.
+
+## 26.2 The Inheritance Chain of Pain
+
+```typescript
+class Entity { }
+class NamedEntity extends Entity { }
+class TimestampedEntity extends NamedEntity { }
+class AuditableEntity extends TimestampedEntity { }
+class SoftDeletableEntity extends AuditableEntity { }
+class VersionedEntity extends SoftDeletableEntity { }
+class ValidatableEntity extends VersionedEntity { }
+class SerializableEntity extends ValidatableEntity { }
+class User extends SerializableEntity { }
+```
+
+Eight levels of inheritance. To add a field, trace through 9 files. To understand what `User` does, read 9 class definitions. Composition over inheritance? Sounds like communism. Each layer adds exactly one feature because someone read that classes should have one responsibility. They missed the part where you shouldn't solve this with inheritance. `super.super.super.super.super.super.super.init()` is a real call that happens.
+
+## 26.3 The Interface Explosion
+
+```typescript
+interface IReadable { read(): Data; }
+interface IWritable { write(data: Data): void; }
+interface IReadableWritable extends IReadable, IWritable { }
+interface IDeletable { delete(): void; }
+interface IReadableWritableDeletable extends IReadableWritable, IDeletable { }
+interface IQueryable { query(q: Query): Data[]; }
+interface IFullyFeatured extends IReadableWritableDeletable, IQueryable { }
+interface ICacheable { cache(): void; invalidate(): void; }
+interface IFullyFeaturedCacheable extends IFullyFeatured, ICacheable { }
+
+class UserRepository implements IFullyFeaturedCacheable {
+    // Must implement 8 methods from 6 interfaces
+}
+```
+
+---
+
+# Chapter 27: Async/Await Abuse
+
+## 27.1 The Sequential Await
+
+```typescript
+async function fetchAllData(): Promise<void> {
+    const users = await fetchUsers();
+    const products = await fetchProducts();
+    const orders = await fetchOrders();
+    const payments = await fetchPayments();
+    const analytics = await fetchAnalytics();
+}
+```
+
+Five independent API calls, made sequentially. Total time: sum of all calls. Could be parallel. Won't be. If each call takes 200ms, this function takes 1 second. `Promise.all()` would make it 200ms. But that requires understanding that these calls don't depend on each other, and reading code is hard. The developer thought `await` means "professional code."
+
+## 27.2 The Await Inside Map
+
+```typescript
+const results = users.map(async user => {
+    const details = await fetchUserDetails(user.id);
+    return { ...user, details };
+});
+
+// results is Promise<User>[], not User[]
+// This developer will discover this in production
+```
+
+## 27.3 The Try-Catch Everything
+
+```typescript
+async function doEverything(): Promise<void> {
+    try {
+        await step1();
+        await step2();
+        await step3();
+        await step4();
+        await step5();
+        await step6();
+        await step7();
+        await step8();
+        await step9();
+        await step10();
+    } catch (error) {
+        console.log('Something went wrong');
+    }
+}
+```
+
+Which step failed? Doesn't matter. "Something went wrong." Error context? Lost forever. Stack trace? Who needs it. The user will see "Something went wrong" and know exactly how to fix it. This is called "Error Handling Minimalism" - maximum abstraction, minimum usefulness. DevOps will love getting the alert "Something went wrong" at 3 AM.
+
+## 27.4 The .then() After Await
+
+```typescript
+async function confused(): Promise<void> {
+    const data = await fetchData();
+    
+    processData(data).then(result => {
+        saveResult(result).then(saved => {
+            notifyUser(saved).then(() => {
+                console.log('Done');
+            });
+        });
+    });
+}
+```
+
+Mixing async/await with .then() chains. Pick a lane. This function is `async`, uses `await` for the first call, then immediately drops into callback hell for no reason. The `console.log('Done')` will execute AFTER the function returns because those `.then()` chains are floating promises. Nobody is awaiting them. The function appears to complete instantly while background operations continue indefinitely.
+
+---
+
+# Chapter 28: Import/Export Insanity
+
+## 28.1 The Circular Import
+
+```typescript
+// user.ts
+import { Order } from './order';
+export class User {
+    orders: Order[];
+}
+
+// order.ts
+import { User } from './user';
+export class Order {
+    user: User;
+}
+
+// app.ts
+import { User } from './user';
+import { Order } from './order';
+// Sometimes works, sometimes undefined, always mysterious
+```
+
+A user has orders. An order has a user. Both files import each other. Depending on which file gets loaded first by the bundler, one of the imports might be `undefined`. It works in development, breaks in production. Works on Tuesdays, fails on Wednesdays. The fix is to restructure your code, but the workaround is to import dynamically inside the method, creating a terrifying `require()` hidden in what looks like ES6 code.
+
+## 28.2 The Re-Export Chain
+
+```typescript
+// utils/string.ts
+export const trim = (s: string) => s.trim();
+
+// utils/index.ts
+export * from './string';
+export * from './number';
+export * from './date';
+export * from './array';
+export * from './object';
+
+// helpers/index.ts
+export * from '../utils';
+export * from './validators';
+export * from './formatters';
+
+// lib/index.ts
+export * from '../helpers';
+export * from './core';
+
+// index.ts
+export * from './lib';
+
+// Where does `trim` come from? Good luck.
+```
+
+Five levels of re-exports. `trim` is defined in `utils/string.ts` but you import it from `index.ts`. When you Cmd+Click to go to definition, you teleport through 5 files. When there's a naming conflict, nobody knows which `trim` wins. Tree shaking gives up and includes everything. The bundle is 2MB because the re-export chain can't be statically analyzed. This is called "Developer Experience Architecture."
+
+## 28.3 The Default Export Nightmare
+
+```typescript
+// Each file has a different pattern
+
+// user.ts
+export default class User { }
+
+// product.ts
+export default function createProduct() { }
+
+// order.ts
+const order = { };
+export default order;
+
+// config.ts
+export default {
+    apiUrl: 'https://api.example.com',
+    timeout: 5000,
+};
+
+// index.ts
+export default 42;
+
+// Importing:
+import User from './user';  // Class
+import createProduct from './product';  // Function
+import order from './order';  // Object
+import config from './config';  // Object literal
+import theAnswer from './index';  // Number???
+```
+
+---
+
+# Chapter 29: Configuration Catastrophes
+
+## 29.1 The Environment Variable Soup
+
+```typescript
+const config = {
+    database: {
+        host: process.env.DB_HOST || process.env.DATABASE_HOST || process.env.POSTGRES_HOST || 'localhost',
+        port: parseInt(process.env.DB_PORT || process.env.DATABASE_PORT || '5432'),
+        name: process.env.DB_NAME || process.env.DATABASE_NAME || process.env.POSTGRES_DB || 'myapp',
+        user: process.env.DB_USER || process.env.DATABASE_USER || process.env.POSTGRES_USER || 'root',
+        password: process.env.DB_PASSWORD || process.env.DATABASE_PASSWORD || process.env.POSTGRES_PASSWORD || '',
+    },
+    redis: {
+        host: process.env.REDIS_HOST || process.env.CACHE_HOST || 'localhost',
+        port: parseInt(process.env.REDIS_PORT || process.env.CACHE_PORT || '6379'),
+    },
+    // ... 200 more lines
+};
+```
+
+Nobody knows which environment variable is actually being used. Three different naming conventions were tried over the years. The fallback chain is basically archeology. When the database doesn't connect, you check `DB_HOST`, then `DATABASE_HOST`, then `POSTGRES_HOST`, then give up and look at the defaults. `parseInt` without a radix because maybe octal parsing is a feature.
+
+## 29.2 The Hardcoded "Configuration"
+
+```typescript
+const API_URL = 'https://api.production.mycompany.com';  // In the source code
+const API_KEY = 'sk_live_a1b2c3d4e5f6';  // Committed to Git
+const ADMIN_PASSWORD = 'admin123';  // Security through obscurity
+```
+
+## 29.3 The Configuration Spread
+
+```typescript
+// config/database.ts - Database config
+// config/redis.ts - Redis config  
+// config/api.ts - API config
+// config/auth.ts - Auth config
+// lib/settings.ts - More settings
+// utils/constants.ts - Even more settings
+// app/defaults.ts - Default values
+// .env - Environment overrides
+// .env.local - Local overrides
+// .env.development - Dev overrides
+// .env.production - Prod overrides
+// docker-compose.yml - Container config
+// kubernetes/configmap.yaml - K8s config
+
+// To find where TIMEOUT is defined: grep -r "TIMEOUT" . | wc -l
+// Result: 47 matches
+```
+
+---
+
+# Chapter 30: Testing Theater
+
+## 30.1 The Test That Tests Nothing
+
+```typescript
+describe('User', () => {
+    it('should work', () => {
+        const user = new User();
+        expect(user).toBeDefined();
+    });
+    
+    it('should also work', () => {
+        const user = new User();
+        expect(user).not.toBeNull();
+    });
+    
+    it('should definitely work', () => {
+        const user = new User();
+        expect(user).toBeTruthy();
+    });
+});
+
+// Coverage: 100%
+// Bugs found: 0
+// Confidence: False
+```
+
+## 30.2 The Mock Everything Approach
+
+```typescript
+jest.mock('./database');
+jest.mock('./cache');
+jest.mock('./logger');
+jest.mock('./api');
+jest.mock('./utils');
+jest.mock('./helpers');
+jest.mock('./services');
+jest.mock('./validators');
+
+describe('UserService', () => {
+    it('should create user', async () => {
+        // Everything is mocked
+        // We're testing that mocks return what we told them to return
+        const result = await userService.create(mockUser);
+        expect(mockDatabase.save).toHaveBeenCalledWith(mockUser);
+        expect(result).toEqual(mockResult);
+    });
+});
+
+// Tests pass! Ship it!
+// Production: Immediate failure because actual database has different behavior
+```
+
+## 30.3 The Flaky Test
+
+```typescript
+it('should process in order', async () => {
+    const results: number[] = [];
+    
+    processAsync(1).then(() => results.push(1));
+    processAsync(2).then(() => results.push(2));
+    processAsync(3).then(() => results.push(3));
+    
+    await new Promise(resolve => setTimeout(resolve, 100));
+    
+    expect(results).toEqual([1, 2, 3]);
+});
+
+// Passes locally
+// Fails in CI
+// Passes again when you re-run
+// It's the CI's fault, probably
+```
+
+Race condition in test form. The 100ms timeout is "usually enough" for the async operations to complete. On your fast laptop, it works. On the overloaded CI runner, it sometimes doesn't. The fix is to add more delay. Then more. Eventually you have `setTimeout(resolve, 5000)` and tests take 20 minutes. The real fix is to `await Promise.all()`, but that requires understanding the test.
+
+---
+
+# Chapter 31: Comments That Hurt
+
+## 31.1 The Obvious Comment
+
+```typescript
+// Increment i
+i++;
+
+// Check if user is null
+if (user === null) {
+
+// Return the result
+return result;
+
+// Loop through the array
+for (const item of array) {
+
+// Create a new date
+const date = new Date();
+```
+
+## 31.2 The Lying Comment
+
+```typescript
+// This function calculates the total price including tax
+function calculateDiscount(items: Item[]): number {
+    return items.reduce((sum, item) => sum + item.price * 0.9, 0);
+}
+
+// Maximum retries is 5
+const MAX_RETRIES = 3;
+
+// TODO: Remove this temporary fix (added 2019-03-15)
+const PERMANENT_WORKAROUND = true;
+```
+
+## 31.3 The Commented-Out Code Museum
+
+```typescript
+function processOrder(order: Order): void {
+    // const oldLogic = order.items.map(i => i.price);
+    // const total = oldLogic.reduce((a, b) => a + b, 0);
+    
+    // New implementation (2021-06-15)
+    // const newTotal = calculateTotal(order);
+    
+    // Even newer implementation (2022-01-20)
+    // const newerTotal = calculateTotalV2(order);
+    
+    // Current implementation (2023-03-08)
+    // Actually we went back to the old way
+    // const currentTotal = order.items.map(i => i.price).reduce((a, b) => a + b, 0);
+    
+    // Final implementation (2024-02-14)
+    const total = order.total; // It was a field all along
+    
+    // Keep the old code in case we need it
+    /* 
+    function legacyCalculation() {
+        // 200 lines of commented code
+    }
+    */
+}
+```
+
+## 31.4 The Passive-Aggressive Comment
+
+```typescript
+// I don't know why this works but it does, don't touch it
+const magic = value ^ (value >> 31);
+
+// Whoever wrote this should be fired
+function legacyProcess(): void { }
+
+// This is wrong but the PM insisted
+const hardcodedValue = 42;
+
+// Future developer: I'm sorry
+```
+
+Code comments as therapy. These comments document not what the code does, but the emotional state of the developer who wrote it. The XOR trick comment is a cry for help. The "whoever wrote this" comment was written by the same person 6 months ago. The apology is genuine but insufficient. These comments will outlive the codebase.
+
+---
+
+# Chapter 32: The Copy-Paste Manifesto
+
+## 32.1 The Repeated Function
+
+```typescript
+function validateUserEmail(email: string): boolean {
+    const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
+    return regex.test(email);
+}
+
+function validateAdminEmail(email: string): boolean {
+    const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
+    return regex.test(email);
+}
+
+function validateGuestEmail(email: string): boolean {
+    const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
+    return regex.test(email);
+}
+
+function validateSupportEmail(email: string): boolean {
+    const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
+    return regex.test(email);
+}
+```
+
+Four functions. Identical logic. If you need to change the regex, update it in 4 places. Or 3. You'll forget one. In 6 months there will be a bug report: "Guest email validation accepts invalid emails but User validation doesn't." Because someone fixed 3 of the 4 copies. This is DRY's evil twin: WET (Write Everything Twice, or Thrice, or Frice).
+
+## 32.2 The Almost-Identical Functions
+
+```typescript
+function processUserOrder(user: User, order: Order): Result {
+    validateUser(user);
+    validateOrder(order);
+    const total = calculateTotal(order);
+    const tax = calculateTax(total);
+    const discount = calculateUserDiscount(user, total);
+    const finalTotal = total + tax - discount;
+    saveOrder(user.id, order, finalTotal);
+    sendConfirmationEmail(user.email, order);
+    return { success: true, total: finalTotal };
+}
+
+function processGuestOrder(guest: Guest, order: Order): Result {
+    validateGuest(guest);
+    validateOrder(order);
+    const total = calculateTotal(order);
+    const tax = calculateTax(total);
+    const discount = 0; // Guests don't get discounts
+    const finalTotal = total + tax - discount;
+    saveOrder(guest.sessionId, order, finalTotal);
+    sendConfirmationEmail(guest.email, order);
+    return { success: true, total: finalTotal };
+}
+```
+
+95% identical. Could be one function with a parameter. Won't be. When someone adds a "feature flag check" to `processUserOrder`, they'll forget to add it to `processGuestOrder`. Three months later: "Why don't guest checkouts have the new feature?" Because nobody remembered there were two nearly-identical functions doing the same thing differently.
+
+---
+
+# Chapter 33: Memory Leaks as a Service
+
+## 33.1 The Event Listener Accumulator
+
+```typescript
+class Component {
+    init(): void {
+        window.addEventListener('resize', this.handleResize);
+        window.addEventListener('scroll', this.handleScroll);
+        document.addEventListener('click', this.handleClick);
+    }
+    
+    // No cleanup method
+    // Every time init() is called, new listeners are added
+    // They're never removed
+    // Memory usage: 📈
+}
+```
+
+## 33.2 The Closure Trap
+
+```typescript
+function createProcessor(): () => void {
+    const hugeData = new Array(1000000).fill('x');
+    
+    return function process(): void {
+        console.log('Processing');
+        // hugeData is never used but captured in closure
+        // 1MB leaked per call to createProcessor
+    };
+}
+
+const processors: Array<() => void> = [];
+for (let i = 0; i < 1000; i++) {
+    processors.push(createProcessor());
+}
+// Congratulations, you've leaked 1GB
+```
+
+The closure captures `hugeData` because it's in scope, even though it's never used. Each call to `createProcessor` allocates 1MB that can never be garbage collected because the returned function holds a reference to it. After 1000 calls, you've used 1GB of RAM to store 1000 functions that print "Processing". The fix is to not capture things you don't need, but that requires understanding closures.
+
+## 33.3 The Cache That Never Forgets
+
+```typescript
+const cache = new Map<string, any>();
+
+function getCached(key: string): any {
+    if (cache.has(key)) {
+        return cache.get(key);
+    }
+    const value = expensiveComputation(key);
+    cache.set(key, value);
+    return value;
+}
+
+// Cache grows forever
+// No TTL
+// No max size
+// No eviction policy
+// Eventually: Out of memory
+```
+
+---
+
+# Chapter 34: Security by Obscurity
+
+## 34.1 The Client-Side Validation Only
+
+```typescript
+// frontend.ts
+function submitPayment(amount: number): void {
+    if (amount <= 0) {
+        alert('Invalid amount');
+        return;
+    }
+    if (amount > userBalance) {
+        alert('Insufficient funds');
+        return;
+    }
+    api.post('/payment', { amount });
+}
+
+// backend.ts
+app.post('/payment', (req, res) => {
+    const { amount } = req.body;
+    processPayment(amount);  // No validation
+    res.json({ success: true });
+});
+
+// Attacker: curl -X POST /payment -d '{"amount": -1000000}'
+```
+
+## 34.2 The Hidden Admin Route
+
+```typescript
+// "Secret" admin endpoint
+app.get('/api/admin-portal-do-not-share-3847', adminHandler);
+
+// Security: If they don't know the URL, they can't hack it
+// Reality: It's in the JavaScript bundle, network tab, and git history
+```
+
+Security through obscurity. The admin panel is "protected" by having a weird URL. No authentication, no authorization, just vibes. The URL was committed to Git in 2019. It's in the Wayback Machine. A former employee posted it on Hacker News. Three security researchers have found it but you've ignored their emails. The "3847" was someone's PIN code.
+
+## 34.3 The Obfuscated Password
+
+```typescript
+const password = atob('YWRtaW4xMjM=');  // "admin123" in base64
+const apiKey = 'sk_live_' + 'a1b2c3d4'.split('').reverse().join('');
+
+// "Encrypted" for security
+```
+
+Base64 is not encryption. Everyone knows this. And yet, here we are. The developer thought "if I encode it, hackers can't read it." Hackers can decode base64 in their sleep. The API key is "protected" by being stored backwards. `sk_live_4d3c2b1a`. Brilliant. This is why security audits exist and also why security auditors drink.
+
+---
+
+# Chapter 35: The GitHub Actions Poetry
+
+## 35.1 The Build That Builds
+
+```yaml
+name: CI
+on: push
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - run: npm install
+      - run: npm run build
+      - run: npm test
+      # No artifact upload
+      # No deployment
+      # No notifications
+      # It just... builds. And then disappears.
+```
+
+## 35.2 The Retry Until It Works
+
+```yaml
+- name: Run flaky tests
+  run: npm test || npm test || npm test
+  # Third time's the charm
+```
+
+Instead of fixing flaky tests, we simply run them three times. If they pass once, that counts as passing. This is the CI equivalent of "have you tried turning it off and on again." The test suite takes 15 minutes, but with retries it can take up to 45 minutes. Worth it to avoid investigating why `setTimeout(100)` isn't enough on the CI runner.
+
+## 35.3 The "Skip CI" Commit History
+
+```
+fix typo [skip ci]
+fix another typo [skip ci]
+actually fix the typo [skip ci]
+ok this time for real [skip ci]
+why is this not working [skip ci]
+AAAAAAAAA [skip ci]
+fixed [skip ci]
+actually fixed
+```
+
+---
+
+# Chapter 36: The Dependency Addiction
+
+## 36.1 The node_modules Black Hole
+
+```json
+{
+  "dependencies": {
+    "left-pad": "^1.3.0",
+    "is-odd": "^3.0.1",
+    "is-even": "^1.0.0",
+    "is-number": "^7.0.0",
+    "is-string": "^1.0.7",
+    "is-array": "^1.0.1",
+    "is-object": "^1.0.2",
+    "is-function": "^1.0.2",
+    "is-boolean-object": "^1.1.2",
+    "is-null": "^1.0.0",
+    "is-undefined": "^1.0.0"
+  }
+}
+```
+
+11 packages to check types. `typeof` is too mainstream. `is-even` literally depends on `is-odd` and returns `!isOdd(n)`. This is real. These packages have millions of weekly downloads. Your node_modules is 847MB for a hello world app. Each package has 47 dependencies of its own. The dependency tree looks like a fractal of poor decisions.
+
+## 36.2 The Version Roulette
+
+```json
+{
+  "dependencies": {
+    "critical-library": "*",
+    "another-library": "latest",
+    "yet-another": ">=1.0.0"
+  }
+}
+```
+
+Today's build might be completely different from yesterday's. Excitement! `*` means "give me whatever version exists right now, I trust the npm ecosystem completely." `latest` means the same thing but with more confidence. `>=1.0.0` means "any version from 2015 to heat death of the universe." When your production breaks, you get to play "which of the 847 transitive dependencies released a breaking change today."
+
+## 36.3 The Security Advisory Graveyard
+
+```
+npm audit
+
+found 847 vulnerabilities (12 low, 234 moderate, 589 high, 12 critical)
+
+run `npm audit fix` to fix them, or `npm audit` for details
+```
+
+```
+npm audit fix
+
+fixed 0 of 847 vulnerabilities
+```
+
+Ship it. The vulnerabilities are probably fine. Most of them are in dev dependencies. Some are in test frameworks. A few are in the actual code that runs in production and handles user data. But the fix would require updating to a major version that has breaking changes, and that would require testing, and we don't have time for that. The security advisory email goes to a shared inbox that nobody checks.
+
+---
+
+# Chapter 37: The Production Checklist (Extended Edition)
+
+Before deploying to production, verify:
+
+- [ ] All console.logs are still in the code
+- [ ] At least one TODO comment from 2019
+- [ ] Hardcoded URL pointing to localhost:3000
+- [ ] .env.example committed but .env gitignored (values unknown)
+- [ ] node_modules accidentally committed at some point in history
+- [ ] At least one `// @ts-ignore` or `// eslint-disable-next-line`
+- [ ] API keys visible in network tab
+- [ ] No rate limiting on any endpoint
+- [ ] No input validation on backend
+- [ ] Passwords stored as MD5 (or plain text for simplicity)
+- [ ] CORS set to `*`
+- [ ] npm packages last updated 3 years ago
+- [ ] No error monitoring
+- [ ] No backup strategy
+- [ ] "It works on my machine" documented as deployment guide
+- [ ] At least one npm package with 0.0.1 version you wrote yourself
+- [ ] A try-catch that catches everything and logs nothing
+- [ ] An endpoint that returns stack traces to clients
+- [ ] Secrets in the README "for easy setup"
+- [ ] A database migration that "should probably never run in production"
+- [ ] A feature flag that's been "temporary" for 2 years
+- [ ] A cron job that nobody remembers scheduling
+- [ ] Admin credentials: admin/admin
+- [ ] A commented-out security check "for testing"
+- [ ] A "quick fix" deployed on Friday at 5pm
+
+---
+
+# Appendix A: The Complete Checklist
+
+Before submitting your PR, ensure you have:
+
+- [ ] Used at least 3 levels of underscores for privacy
+- [ ] Created intermediate variables named `c`, `t`, or `r`
+- [ ] Added at least one empty catch block
+- [ ] Used `reduce()` where `every()` or `some()` would work
+- [ ] Wrapped async/await in a Promise constructor
+- [ ] Used `JSON.parse(JSON.stringify())` for cloning
+- [ ] Added `|| {}` to handle undefined objects
+- [ ] Used `indexOf() >= 0` instead of `includes()`
+- [ ] Mutated at least one function parameter
+- [ ] Left a TODO comment you'll never address
+- [ ] Added a `console.warn` in library code
+- [ ] Used `as any` at least once
+- [ ] Created a magic buffer without explanation
+
+---
+
+# About the Author
+
+The author learned JavaScript from Stack Overflow snippets circa 2015, never read the language spec, and doesn't understand why patterns exist. Every anti-pattern from "JavaScript: The Bad Parts" exists in their code simultaneously.
+
+Their code works despite itself, not because of good design.
+
+They have mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass mass downloads.
+
+---
+
+# Epilogue: The Cycle Continues
+
+And so the cycle continues.
+
+Someone writes code like this. It gets mass mass mass mass mass mass mass downloads. New developers learn from it. They copy the patterns. They become senior developers. They write more code like this. New developers learn from them.
+
+The code works despite itself, not because of good design. Millions of dollars flow through `const c = this.__CACHE`. People's money, handled by `(input || {}).partialSig`.
+
+Somewhere, a junior developer is reading bitcoinjs-lib source code, thinking "This is how the professionals do it."
+
+They will carry these patterns into their next job.
+
+And the mass mass mass mass mass mass mass mass mass mass continues.
+
+**The Circle of Mass:**
+```
+Developer learns from bad code
+         ↓
+Developer writes bad code
+         ↓
+Bad code gets mass downloads
+         ↓
+New developer learns from bad code
+         ↓
+    (repeat mass infinitely)
+```
+
+**Final Statistics:**
+- Lines of code analyzed: 1,847
+- Violations of basic principles: 847
+- Empty catch blocks: Yes
+- Underscores used for "privacy": _______________________
+- Money at risk: Mass
+- Fucks given by original developers: `catch (_) {}`
+- TODO comments that will be addressed: 0
+- GitHub stars: Many (this is the problem)
+
+**Dedication:**
+This book is dedicated to everyone who has mass mass mass debugged a getter that was secretly installed by `Object.defineProperty` at runtime, wondered why `c.__FEE` is undefined when they definitely set `cache.__FEE`, or mass questioned their mass career choices while staring at `return results.reduce((final, res) => res === true && final, true)`.
+
+You are not alone. We are all mass mass mass in this together.
+
+**Remember:** The TypeScript Law exists because code like this exists. Someone had to draw the line and say "no, this is not acceptable, I don't care how many GitHub stars it has."
+
+**Score: 8/100**
+
+The 8 points are for:
+- It compiles
+- It has some type annotations  
+- It technically works (probably)
+- JSDoc comments exist (even if the code contradicts them)
+
+Why it's 8, not 0:
+
+It's functional garbage, not non-functional garbage. Someone shipped this and Bitcoin transactions were signed. That's worth something.
+
+---
+
+*"This is what happens when someone learns JavaScript from Stack Overflow snippets circa 2015, never reads the language spec, and doesn't understand why patterns exist. Every anti-pattern from 'JavaScript: The Bad Parts' exists here simultaneously."*
+
+*"The code works despite itself, not because of good design."*
+
+---
+
+*fin.*
+
+*Now go read the TypeScript Law and write actual good code.*
+
+*Or don't. I'm a book, not a cop.*