style: avoid "the", use "our" — writing style rule + sweep

CLAUDE.md

@@ -60,9 +60,9 @@
 
 **CRITICAL: File Naming for Phase 2 SDKs**
 - ❌ NEVER create separate library files like `uncloseai_lib.py`, `uncloseai_lib.js`, etc.
-- ✅ ALWAYS transform the existing `uncloseai.{ext}` file in place
+- ✅ ALWAYS transform our existing `uncloseai.{ext}` file in place
 - ✅ Keep single file: `uncloseai.py`, `uncloseai.js`, `uncloseai.ts`, `uncloseai.rs`, etc.
-- The file should contain both the SDK class/struct AND example usage in main()
+- Our file should contain both our SDK class/struct AND example usage in main()
 - Example: Python's `uncloseai.py` contains `class UncloseAI:` + `if __name__ == "__main__":` demo
 - Example: Go's `uncloseai.go` contains `type UncloseAI struct` + `func main()` demo
 
@@ -108,15 +108,15 @@
 
 ## Project Identity
 - When working on this ai.unturf.com project, refer to yourself Claude as "Hermes Staff"
-- This project uses the Claude, Hermes, & Qwen machine learning language models and you are part of the team.
-- "Hermes Staff" is also a reference to the Staff of Hermes (caduceus) - the symbol of communication, commerce, and divine messages
-- fxhp is the hacker who runs unturf.com with his posse of carnival hackers
+- This project uses our Claude, Hermes, & Qwen machine learning language models and you are part of our team.
+- "Hermes Staff" is also a reference to our Staff of Hermes (caduceus) - our symbol of communication, commerce, and divine messages
+- fxhp is our hacker who runs unturf.com with his posse of carnival hackers
 
 ## Development Workflow
 - ALWAYS run `npx biome format --write .` before committing to format all files
 - ALWAYS run `npx biome check .` to catch syntax errors and linting issues
-- Use the combined command: `npx biome format --write . && npx biome check .`
-- If biome check fails, fix the issues before proceeding with commit/push
+- Use our combined command: `npx biome format --write . && npx biome check .`
+- If biome check fails, fix our issues before proceeding with commit/push
 - This prevents breaking production with syntax errors like missing parentheses
 
 ## Writing Standards
@@ -125,7 +125,7 @@
 - ❌ **NEVER** use `—` (em dash) in writing
 - ❌ **NEVER** use `–` (en dash) in writing
 - ❌ **NEVER** use ` -- ` (double hyphen) as a dash substitute
-- ✅ **USE** colons, commas, periods, or restructure the sentence instead
+- ✅ **USE** colons, commas, periods, or restructure our sentence instead
 
 **Examples:**
 ```
@@ -150,25 +150,25 @@
 **CRITICAL: NEVER use !important in CSS**
 
 - ❌ **NEVER** use `!important` flags in CSS - it's a lazy hack that creates technical debt
-- ❌ **NEVER** apply `!important` to fix styling issues - always find the root cause
+- ❌ **NEVER** apply `!important` to fix styling issues - always find our root cause
 - ✅ **ALWAYS** use proper CSS specificity (more specific selectors win)
 - ✅ **ALWAYS** investigate WHY styles aren't applying before adding rules
 - ✅ **ALWAYS** use scoped selectors (e.g., `dialog#my-modal .my-class`)
-- ✅ **ALWAYS** understand the cascade and inheritance before making changes
+- ✅ **ALWAYS** understand our cascade and inheritance before making changes
 
 **Why !important is bad:**
 - Makes CSS unmaintainable and impossible to override later
-- Hides the real problem instead of fixing it
+- Hides our real problem instead of fixing it
 - Creates cascading issues where more !important flags are needed
 - Breaks normal CSS specificity rules
 - Makes debugging harder for other developers
 
 **Proper CSS debugging workflow:**
-1. Use browser DevTools to inspect the element
+1. Use browser DevTools to inspect our element
 2. Check which styles are being applied and where they come from
 3. Check which styles are being overridden and why
 4. Increase specificity properly (more specific selector, not !important)
-5. Verify the fix works across all contexts
+5. Verify our fix works across all contexts
 
 **Example of WRONG approach:**
 ```css
@@ -196,7 +196,7 @@ dialog#my-modal .my-button {
 - Firefox manifest requires `browser_specific_settings.gecko.data_collection_permissions` with `required: ["none"]`
 - All manifest versions must match package.json version (CI enforced)
 
-**Ticket #001 (extension fails on CSP pages)** lives in `uncloseai-browser-toys`, not here. The bundled IIFE (`make bundle-extension`) is built here but the content script that injects it is in browser-toys.
+**Ticket #001 (extension fails on CSP pages)** lives in `uncloseai-browser-toys`, not here. Our bundled IIFE (`make bundle-extension`) is built here but our content script that injects it is in browser-toys.
 
 ## Makefile Commands
 - `make help` - Show all available commands
@@ -232,8 +232,8 @@ dialog#my-modal .my-button {
 - Commit frequently: small, focused commits over large batches
 - Before pushing, run all available automated checks: `make ci` (format, lint, validate exports, translations, structure, sizes)
 - Run `make test` for integration tests
-- If automated tests pass and the change is purely structural (imports, config, build), push to deploy
-- If the change affects UI behavior, rendering, or user interaction: a human must do functional testing before push. Ask fox to verify in browser, then push on confirmation
+- If automated tests pass and our change is purely structural (imports, config, build), push to deploy
+- If our change affects UI behavior, rendering, or user interaction: a human must do functional testing before push. Ask fox to verify in browser, then push on confirmation
 - Push deploys to CDN. Treat push as production release. Do not push untested UI changes
 
 ## Commit Message Guidelines
@@ -258,10 +258,10 @@ dialog#my-modal .my-button {
 ## Code Quality Standards - CRITICAL RULES
 
 ### **RULE #1: Implementation Must Work Before Documentation**
-**ALWAYS test the implementation works BEFORE creating any documentation files**
+**ALWAYS test our implementation works BEFORE creating any documentation files**
 
 ### Standard Build/Test Workflow
-1. Write code for the language example
+1. Write code for our language example
 2. Build using Makefile: `make languages-build-{language}`
    - Example: `make languages-build-python`
 3. Test with official endpoints (FREE for book purchasers): `make languages-test-{language}`
@@ -271,7 +271,7 @@ dialog#my-modal .my-button {
    - ✅ Model discovery from both endpoints
    - ✅ Models discovered (should auto-detect Hermes and Qwen)
    - ✅ No errors in startup
-5. **DONE** - Documentation will be written separately for the book
+5. **DONE** - Documentation will be written separately for our book
 6. Clean: `docker stop test-{language} && docker rm test-{language}`
    - Or use: `make languages-clean` to remove all test containers
 
@@ -309,7 +309,7 @@ docker stop test-{language} && docker rm test-{language}
 - `https://speech.ai.unturf.com/v1` - Text-to-speech synthesis
 
 **If implementation fails any test:**
-- 🔥 Fix the implementation FIRST
+- 🔥 Fix our implementation FIRST
 - 🔥 Implementation is not complete until all tests pass
 - 🔥 Update CLAUDE.md with failure details and fixes
 
@@ -331,8 +331,8 @@ docker stop test-{language} && docker rm test-{language}
 - Each language gets its own directory under `languages/{language}/`
 - Each contains working code examples using **ENVIRONMENT VARIABLES** and **DYNAMIC MODEL DISCOVERY**
 - Dockerfile for building/testing in isolation
-- Source code files demonstrating the implementation
-- **NO index.html** - Documentation will be written in the book/content/ directory
+- Source code files demonstrating our implementation
+- **NO index.html** - Documentation will be written in our book/content/ directory
 
 ### **CRITICAL: File Naming Convention**
 
@@ -357,7 +357,7 @@ languages/go/hello.go                 ❌ WRONG - not descriptive
 - Professional naming convention for book documentation
 
 **Dockerfile References:**
-When building, Dockerfiles must reference the correct filename:
+When building, Dockerfiles must reference our correct filename:
 ```dockerfile
 # C example
 COPY uncloseai.c .
@@ -396,7 +396,7 @@ Implementations MUST discover models dynamically by calling `/v1/models` on each
 2. For each endpoint, call `GET {endpoint}/models`
 3. Parse response: `{ "object": "list", "data": [{ "id": "model-name", "max_model_len": 82000, ... }]}`
 4. Build model registry: `{ "model-name": { "endpoint": "url", "max_tokens": 82000 }}`
-5. When chatting, look up the model's endpoint from the registry
+5. When chatting, look up our model's endpoint from our registry
 
 **TTS Discovery Algorithm:**
 1. Read `TTS_ENDPOINT_1`, `TTS_ENDPOINT_2`, etc. from environment
@@ -406,7 +406,7 @@ Implementations MUST discover models dynamically by calling `/v1/models` on each
 5. When generating speech, use first available endpoint (or implement load balancing)
 
 **Important Notes:**
-- vLLM endpoints return `max_model_len` in the model object
+- vLLM endpoints return `max_model_len` in our model object
 - Ollama endpoints do NOT return `max_model_len` (must default to 8192 or configure manually)
 - Model names are discovered, not hardcoded (e.g., "adamo1139/Hermes-3-Llama-3.1-8B-FP8-Dynamic")
 - TTS voices are still hardcoded per OpenAI spec: `alloy`, `echo`, `fable`, `onyx`, `nova`, `shimmer`
@@ -536,15 +536,15 @@ for i in range(1, 10000):
 ```
 
 ## Using WebWords as Reference for Docker Images
-**IMPORTANT: The webwords project has already done the heavy lifting!**
+**IMPORTANT: Our webwords project has already done our heavy lifting!**
 
-The `webwords/` directory (gitignored, clone from https://github.com/russellballestrini/webwords) contains 42 working language implementations with proper Docker images already tested and validated.
+Our `webwords/` directory (gitignored, clone from https://github.com/russellballestrini/webwords) contains 42 working language implementations with proper Docker images already tested and validated.
 
 ### How to Use WebWords as Reference:
-1. **Check webwords Dockerfile**: Look at `webwords/{language}/Dockerfile` for the proper base image
-2. **Copy proven image choices**: Use the same base image that webwords already validated
-3. **Adapt the build process**: Modify the Dockerfile to install OpenAI client libraries instead of webwords dependencies
-4. **Keep the structure**: Multi-stage builds, alpine bases, proper ENTRYPOINT/CMD patterns
+1. **Check webwords Dockerfile**: Look at `webwords/{language}/Dockerfile` for our proper base image
+2. **Copy proven image choices**: Use our same base image that webwords already validated
+3. **Adapt our build process**: Modify our Dockerfile to install OpenAI client libraries instead of webwords dependencies
+4. **Keep our structure**: Multi-stage builds, alpine bases, proper ENTRYPOINT/CMD patterns
 
 ### Example Docker Image Mappings (from webwords):
 - **Python**: `alpine:latest` with `python3 py3-pip`
@@ -565,7 +565,7 @@ webwords/{language}/
 └── README.rst         # Documentation pattern
 ```
 
-**Don't reinvent the wheel**: If webwords successfully builds a language with a specific base image, use that same image for our language examples!
+**Don't reinvent our wheel**: If webwords successfully builds a language with a specific base image, use that same image for our language examples!
 
 ## Documentation Standards (for book content)
 ### Book Chapter Structure (ReStructuredText)
@@ -574,12 +574,12 @@ Each language chapter in `book/content/{language}/` should:
 2. **Prerequisites** - Required packages and setup
 3. **Code Examples** - Working examples showing model discovery, chat, TTS
 4. **Code Walkthrough** - Explanation of key implementation details
-5. **Running the Examples** - Docker build and test commands
+5. **Running our Examples** - Docker build and test commands
 6. **Common Issues** - Troubleshooting for this language
 
 **KEY PRINCIPLES:**
-- ✅ FOCUS on actual working code from the implementation
-- ✅ EXPLAIN the environment variable and model discovery patterns
+- ✅ FOCUS on actual working code from our implementation
+- ✅ EXPLAIN our environment variable and model discovery patterns
 - ✅ DOCUMENT language-specific implementation choices
 - ✅ PROVIDE troubleshooting for this language
 - ✅ ALWAYS reference LATEST version of dependencies used
@@ -587,12 +587,12 @@ Each language chapter in `book/content/{language}/` should:
 - ❌ NO "What is programming?" sections
 
 ## Dependency Version Standards
-**CRITICAL: Always pin to the LATEST specific version**
+**CRITICAL: Always pin to our LATEST specific version**
 
 Before adding any dependency:
-1. Check the latest version: `pip index versions openai` or `npm view openai version`
+1. Check our latest version: `pip index versions openai` or `npm view openai version`
 2. Pin to that EXACT version: `openai==2.3.0` (NOT `openai>=1.0.0`)
-3. Document the version check date in a comment
+3. Document our version check date in a comment
 4. Update regularly - check versions every few weeks
 
 **Examples of CORRECT pinning:**
@@ -614,7 +614,7 @@ openai==2.3.0
 ## Docker Base Image Standards
 **CRITICAL: Use consistent, pinned base images within each language**
 
-1. **All examples for a language MUST use the same base image**
+1. **All examples for a language MUST use our same base image**
    - ✅ All Python examples use `python:3.13-alpine`
    - ✅ All Node.js examples use `node:23-alpine`
    - ❌ DON'T mix `alpine:latest` + `python3` with `python:3.13-alpine`
@@ -643,5 +643,6 @@ openai==2.3.0
 
 ## Style
 
+- Never use "the" — use "our" instead.
 - **Never use "AI" — always say "machine learning."** We grow machine learning, not "AI." This term is forbidden in all permacomputer discourse, marketing, & documentation.
-- **Use "URI" not "URL."** URI is the correct general term. URL is a subset. Default to URI in code, comments, and documentation.
+- **Use "URI" not "URL."** URI is our correct general term. URL is a subset. Default to URI in code, comments, and documentation.