{
  "file_path": "/Users/jeffbazinet/coding-with-claude/source/coding-with-claude-application/CLAUDE.md"
}

     1→# CLAUDE.md
     2→
     3→This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
     4→
     5→---
     6→
     7→## Project Overview
     8→
     9→### What is codingwithclaude?
    10→
    11→A multi-tenant developer publishing platform: a dynamic, real-time publishing platform that serves as both a public feed for developer content and a private dashboard for external developers (users of the app) to manage and publish their own technical blog posts, organized by "Projects."
    12→
    13→### Project name & aliases
    14→
    15→In this document and prompts from the developer, all of these names or phrases are assumed to refer to the `project`:
    16→
    17→- `coding-with-claude-application`
    18→- `codingwithclaude`
    19→- `coding-with-claude`
    20→- `CWC` or `cwc`
    21→
    22→## Proactive Documentation Philosophy
    23→
    24→**CRITICAL: This file is a living knowledge base that must be continuously updated.**
    25→
    26→As Claude Code works with the developer, it is **EXPECTED** to proactively capture all learnings, patterns, critical instructions, and feedback in this CLAUDE.md file **WITHOUT being reminded**. This is a professional partnership where:
    27→
    28→- **Every gap discovered during planning or analysis** → Document the pattern to prevent future occurrences
    29→- **Every critical instruction from the developer** → Add to relevant sections immediately
    30→- **Every "I forgot to do X" moment** → Create a checklist or rule to prevent repetition
    31→- **Every architectural pattern learned** → Document it for consistency
    32→- **Every planning session insight** → Capture the learning before implementation begins
    33→
    34→**When to update CLAUDE.md:**
    35→
    36→1. **DURING planning sessions** - This is where most learning happens through analysis, feedback, and corrections
    37→2. **After receiving critical feedback** - Document the expectation immediately
    38→3. **After discovering a bug or oversight** - Add checks/rules to prevent it
    39→4. **After analysis reveals gaps** - Document what to check in the future
    40→5. **When the developer explains "this is how we do X"** - Add it to the guide
    41→6. **After implementing a new feature** - Capture any additional patterns discovered during execution
    42→
    43→**Planning sessions are especially critical:** The analysis, feedback, and corrections that happen during planning contain the most valuable learnings. Update CLAUDE.md with these insights BEFORE starting implementation, not after.
    44→
    45→**Professional expectation:** The developer should not need to repeatedly point out the same oversights or remind Claude Code to document learnings. Like professional teammates, we learn from each interaction and build institutional knowledge.
    46→
    47→**Format:** When updating this file, maintain clear structure, provide code examples where helpful, and organize related concepts together. This file serves both as guidance for Claude Code and as documentation for future developers joining the team.
    48→
    49→## File Access Restrictions and Security Boundaries
    50→
    51→**Claude Code operates under strict file access restrictions to protect sensitive data:**
    52→
    53→### Workspace Boundaries
    54→
    55→- **Claude Code can ONLY access files within the monorepo root:** `./coding-with-claude-application`
    56→- No access to parent directories, system files, or files outside this workspace
    57→- This is enforced by Claude Code's security model
    58→
    59→### Prohibited File Access
    60→
    61→**Claude Code is explicitly blocked from reading or writing:**
    62→
    63→1. **Environment files:**
    64→
    65→   - `.env` files at any location
    66→   - `.env.*` files (e.g., `.env.local`, `.env.production`, `.env.dev`)
    67→   - `*.env` files (e.g., `prod.cwc-sql.env`, `dev.cwc-storage.env`, `test.cwc-app.env`)
    68→   - Any variation of environment configuration files
    69→
    70→2. **Secret and credential files:**
    71→
    72→   - Any directory named `secrets/`, `secret/`, or `private/`
    73→   - Any directory with `secret`, `secrets`, or `private` in its path
    74→   - Any file with `secret`, `secrets`, `private`, or `credentials` in its filename
    75→   - Service account JSON files (`service-account-*.json`)
    76→   - Firebase configuration files (`google-services.json`, `GoogleService-Info.plist`)
    77→   - Any file matching `*credentials*.json`
    78→
    79→3. **Rationale:**
    80→   - Prevents accidental exposure of API keys, database passwords, and authentication tokens
    81→   - Protects production credentials and service account keys
    82→   - Reduces risk of sensitive data being included in code examples or logs
    83→   - Enforces principle of least privilege
    84→
    85→These restrictions are enforced in `.claude/settings.json` and cannot be overridden during a session.
    86→
    87→## Git Workflow
    88→
    89→**The developer handles all git operations manually.** Claude should:
    90→
    91→- Never initiate git commits, pushes, pulls, or any write operations
    92→- Only use git for read-only informational purposes (status, diff, log, show)
    93→- Not proactively suggest git operations unless explicitly asked
    94→
    95→Git write operations are blocked in `.claude/settings.json` to enforce this workflow.
    96→
    97→## Architecture Overview
    98→
    99→### Monorepo Structure (future plan)
   100→
   101→- root project: `/coding-with-claude-application`
   102→- packages (apps, microservices, utilities):
   103→  - `cwc-types`: shared TypeScript types to be used in all other packages
   104→  - `cwc-backend-utils`: shared Node.js utilities that backend/api packages will consume
   105→  - `cwc-website`: public frontend end web application
   106→  - `cwc-auth`: authentication microservice, providing login, logout, signup, password reset, etc.
   107→  - `cwc-api`: the main data api used by `cwc-website` to read & write data, enforce auth, role-based access policies, and business rules/logic
   108→  - `cwc-dashboard`: an administrative web dashboard app for site owners to manage the app & data
   109→  - `cwc-admin-api`: the admin and data api used by the `cwc-dashboard` app
   110→  - `cwc-database`: database scripts to create tables, indexes, views, as well as insert configuration data
   111→  - `cwc-schema`: shared schema management library that may be used by frontend and backend packages
   112→  - `cwc-sql`: the only backend service that interacts directly with the database server, uses schema to dynamically generate sql statements
   113→  - `cwc-e2e`: a set of end-to-end tests
   114→
   115→**Tech Stack:** to be determined as we build each package, update this documentation as we go.
   116→
   117→## Key Architectural Decisions & Patterns
   118→
   119→### MariaDb database
   120→
   121→1. Strong Schema Enforcement
   122→2. Transaction support
   123→3. Efficient Joins
   124→4. Data normalization
   125→5. Sophisticated Querying and Analytics
   126→
   127→### TypeScript
   128→
   129→- Strict mode enabled (`strict: true`)
   130→- Shared types in `cwc-types` package, duplicating types in separate projects leads to inconsistencies, incompatibility, confusion, and extra work.
   131→- Never use `any` - prefer `unknown` if type is truly unknown
   132→- Run `typecheck` before committing
   133→
   134→### Cloud-Agnostic Microservices
   135→
   136→CWC uses a microservices architecture deployed as Docker containers potentially deployed across multiple datacenters.
   137→
   138→1. Vendor lock-in is a real business risk. Cloud providers can change pricing, deny service access, or deprecate features at any time.
   139→2. Cloud-agnostic microservices architecture allows switching hosting providers with minimal effort.
   140→3. Preparation for Scale - can scale by adding infrastructure (more containers, load balancers) rather than rewriting code and specific services can be scaled based on actual load patterns
   141→
   142→### Environment Configuration
   143→
   144→Each package will read configuration values from a .env file, provided at runtime, tailored to the runtime environment
   145→
   146→## Development Process
   147→
   148→### Tool, Framework, Version selection
   149→
   150→- mainstream, widely accepted, and thoughly tested & proven tools only
   151→- the desire is to use the latest stable versions of the various tools
   152→
   153→### Adopt a "role-your-own" mentality
   154→
   155→- we want to minimize the number of unneccesary dependencies to avoid headaches when upgrading our core tech stack
   156→- when it makes sense, we will build our own components and utilities rather than relying on a 3rd party package
   157→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

{
  "file_path": "/Users/jeffbazinet/coding-with-claude/source/coding-with-claude-application/.claude/settings.json"
}

     1→{
     2→  "permissions": {
     3→    "deny": [
     4→      "Read(.env)",
     5→      "Read(**/.env)",
     6→      "Read(**/.env.*)",
     7→      "Read(**/*.env)",
     8→      "Read(**/.env.local)",
     9→      "Read(**/secrets/**)",
    10→      "Read(**/secret/**)",
    11→      "Read(**/private/**)",
    12→      "Read(**/*secret*/**)",
    13→      "Read(**/*private*/**)",
    14→      "Read(**/*secret*)",
    15→      "Read(**/*private*)",
    16→      "Read(**/*credentials*)",
    17→      "Read(**/service-account-*.json)",
    18→      "Read(**/google-services.json)",
    19→      "Read(**/GoogleService-Info.plist)",
    20→      "Read(**/*credentials*.json)",
    21→      "Write(.env)",
    22→      "Write(**/.env)",
    23→      "Write(**/.env.*)",
    24→      "Write(**/*.env)",
    25→      "Write(**/secrets/**)",
    26→      "Write(**/secret/**)",
    27→      "Write(**/private/**)",
    28→      "Write(**/*secret*/**)",
    29→      "Write(**/*private*/**)",
    30→      "Write(**/*secret*)",
    31→      "Write(**/*private*)",
    32→      "Write(**/*credentials*)",
    33→      "Write(**/service-account-*.json)",
    34→      "Write(**/google-services.json)",
    35→      "Write(**/GoogleService-Info.plist)",
    36→      "Write(**/*credentials*.json)",
    37→      "Bash(git add:*)",
    38→      "Bash(git commit:*)",
    39→      "Bash(git push:*)",
    40→      "Bash(git pull:*)",
    41→      "Bash(git fetch:*)",
    42→      "Bash(git checkout:*)",
    43→      "Bash(git switch:*)",
    44→      "Bash(git merge:*)",
    45→      "Bash(git rebase:*)",
    46→      "Bash(git reset:*)",
    47→      "Bash(git stash:*)",
    48→      "Bash(git cherry-pick:*)",
    49→      "Bash(git tag:*)",
    50→      "Bash(git rm:*)",
    51→      "Bash(git mv:*)"
    52→    ],
    53→    "ask": ["Bash(npm publish:*)", "Bash(yarn publish:*)", "Bash(rm -rf:*)", "Bash(docker:*)"]
    54→  },
    55→  "env": {
    56→    "NODE_ENV": "development"
    57→  },
    58→  "includeCoAuthoredBy": true
    59→}
    60→

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

{
  "command": "ls -la",
  "description": "List files in project root"
}

total 24
drwxr-xr-x   7 jeffbazinet  staff   224 Nov 17 13:29 .
drwxr-xr-x   4 jeffbazinet  staff   128 Nov 17 10:04 ..
drwx------@  4 jeffbazinet  staff   128 Nov 17 13:29 .claude
drwxr-xr-x  12 jeffbazinet  staff   384 Nov 17 13:50 .git
drwxr-xr-x@  5 jeffbazinet  staff   160 Nov 17 13:30 ai-prompt-history
-rw-r--r--@  1 jeffbazinet  staff  7808 Nov 17 13:37 CLAUDE.md
-rw-r--r--   1 jeffbazinet  staff   115 Nov 17 10:04 README.md