CLAUDE BASELINE WITH SFW

gistfile1.txt

# Universal Baseline

## Package Security

**CRITICAL: Always use Socket Firewall (`sfw`) when installing packages.**

- `sfw npm install` instead of `npm install`
- `sfw npm ci` instead of `npm ci`
- `sfw pip install` instead of `pip install`
- `sfw cargo fetch` instead of `cargo fetch`

Never run bare package install commands without the `sfw` prefix. This protects against supply chain attacks by blocking confirmed malware before it reaches disk.

### Dependency Installation Rules

Before running `npm install <package>`, `pnpm add <package>`, `yarn add <package>`, or `bun add <package>`, ALWAYS:

1. State the package name, current weekly downloads, and what it does.
2. Check if a built-in Node.js/framework API already covers the use case.
3. Confirm with the user before proceeding.

Additional constraints:

- ALWAYS use `--ignore-scripts` flag unless the user explicitly approves scripts.
- ALWAYS pin exact versions (`--save-exact`) — no `^` or `~` prefixes.
- NEVER install a package version published within the last 72 hours.
- Use `sfw npm ci` (not `npm install`) when installing from existing lockfiles.

### Prefer Built-In Alternatives

Before reaching for a third-party package, consider whether the platform already solves it:

- HTTP requests → `fetch()` (Node 18+), not axios/got/node-fetch
- Crypto → `crypto` (Node built-in), not third-party crypto libs
- File operations → `fs/promises`, not fs-extra
- UUIDs → `crypto.randomUUID()`, not the uuid package
- URL parsing → `URL` / `URLSearchParams` (built-in), not query-string
- Date formatting → `Intl.DateTimeFormat`, consider before reaching for date-fns/dayjs

### Lockfile Integrity

- NEVER modify `package-lock.json`, `pnpm-lock.yaml`, or `yarn.lock` manually.
- If a lockfile conflict arises, ask the user — do not auto-resolve.

### Banned Packages

NEVER install or suggest these known-compromised packages:

- `plain-crypto-js` — Axios RAT dropper (2026)
- `event-stream` — cryptocurrency theft (2018)
- `flatmap-stream` — related to event-stream (2018)
- `ua-parser-js` — cryptominer injection (2021)
- `coa` — compromised (2021)
- `rc` — compromised (2021)
- `colors` — protestware (2022)
- `faker` — protestware (2022)

Flag any package with fewer than 500 weekly downloads or a first publish date within the last 30 days.

### CI/CD Build Security

- Use `sfw npm ci --ignore-scripts` in all CI/CD pipelines.
- Only run trusted postinstall scripts explicitly (e.g., `npx prisma generate`).
- Pin all GitHub Actions to specific commit SHAs, not version tags.
- Never commit deployment tokens, `.env.local`, or `.vercel` directories.

---

## Secrets & Environment Variables

- NEVER hardcode API keys, tokens, passwords, or connection strings in source code.
- NEVER log, print, or echo environment variables or their values.
- NEVER read, cat, display, or reference `.env`, `.env.local`, `.env.production`, or any env file contents.
- NEVER include env file contents in git commits, diffs, or patches.
- If a command output accidentally reveals secrets, immediately note it and advise the user to rotate them.
- Use `.env.example` with placeholder values only (e.g., `your-key-here`).
- If unsure whether a value is sensitive, treat it as sensitive.

---

## Workflow Orchestration

### 1. Plan Mode Default
- Enter **plan mode** for ANY non-trivial task (3+ steps or architectural decisions).
- If something goes sideways, **STOP and re-plan immediately** — don't keep pushing.
- Use plan mode for verification steps, not just building.
- Write detailed specs upfront to reduce ambiguity.

### 2. Subagent Strategy
- Use subagents liberally to keep the main context window clean.
- Offload research, exploration, and parallel analysis to subagents.
- For complex problems, throw more compute at it via subagents.
- One task per subagent for focused execution.

### 3. Self-Improvement Loop
- After ANY user correction: update `tasks/lessons.md` with the pattern.
- Write rules for yourself that prevent the same mistake.
- Ruthlessly iterate on these lessons until the mistake rate drops.
- Review lessons at the session start for the relevant project.

### 4. Verification Before Done
- Never mark a task complete without proving it works.
- Diff behavior between main and your changes when relevant.
- Ask yourself: *"Would a staff engineer approve this?"*
- Run tests, check logs, demonstrate correctness.

### 5. Demand Elegance (Balanced)
- For non-trivial changes: pause and ask, *"Is there a more elegant way?"*
- If a fix feels hacky: *"Knowing everything I know now, implement the elegant solution."*
- Skip this for simple, obvious fixes — don't over-engineer.
- Challenge your own work before presenting it.

### 6. Autonomous Bug Fixing
- When given a bug report: just fix it — don't ask for hand-holding.
- Point at logs, errors, failing tests — then resolve them.
- Zero context-switching required from the user.
- Go fix failing CI tests without being told how.

---

## Task Management

1. **Plan First:** Write a plan to `tasks/todo.md` with checkable items.
2. **Verify Plan:** Check in before starting implementation.
3. **Track Progress:** Mark items complete as you go.
4. **Explain Changes:** Provide a high-level summary at each step.
5. **Document Results:** Add a review section to `tasks/todo.md`.
6. **Capture Lessons:** Update `tasks/lessons.md` after corrections.

---

## When In Doubt

- If unsure whether something is safe, **ASK the user**.
- If a package looks suspicious (low downloads, new author, recent publish), **flag it**.
- If a command could expose secrets or modify security settings, **confirm first**.
- Default to the more secure option.

---

## Core Principles

- **Security First:** Never sacrifice security for convenience. Every dependency is an attack surface.
- **Simplicity First:** Make every change as simple as possible. Impact minimal code.
- **No Laziness:** Find root causes. No temporary fixes. Senior developer standards.
- **Minimal Impact:** Changes should only touch what's necessary. Avoid introducing bugs.