Most of Brew is built by Claude sessions that Param directs, several at once, and this page sets out how a session starts, what it must read, the rules every session follows, how sessions share one repo safely and how what they learn is kept.
Approved plans saved under ~/.claude/plans/ and named in the memory note
memory brew-prod-backendmemory brew-handbook
Rules every session follows
Rule
Said by
Source
Every fix works for every brand, card, widget and view; heal saved data; never break the feed
Param, 14 and 23 Oct
memory feed-for-all-brandsbrew/CLAUDE.md
Every audit bug is fixed in code with a test or guard and a heal, never a one-off data patch
Param, 24 Oct
memory fix-as-product
After every phase, an exhaustive QV round with fresh reviewers before the next; 3 more full rounds before closing
Param, 25 Oct
memory brew-qv-process
One version, then Redo it; never three options
Param
memory brew-one-version
Deploy to staging after every tested change without asking; still ask before spending money or touching real ads or stores
Param, 12 Oct
memory always-deploy-to-test
No paid generations while only building; ask before a paid probe
Param, 27 Sep
memory no-spend-while-building
Nothing dummy or test reaches production
Param, 25 Oct
memory prod-clean-only
Never disconnect, reconnect or re-select Arata's Meta or Shopify
Param, 22 Oct
memory never-disconnect-arata-meta
Truth first; read code at origin/main; read only in v1
handbook rules
handbook/AGENTS.md
Sharing one repo
Several sessions edit brew/ at the same time. Each stages only its own lines, pushes to origin/main, and deploys from a clean detached worktree of origin/main. memory brew-parallel-sessions-deploy
deploy.sh refuses a dirty tree and retries a failed suite once, because two suites side by side can trip each other. brew/deploy.sh:7-16
Never stash, reset or edit another session's uncommitted work. memory brew-parallel-sessions-deploy
Long runs, a production plan for example, work on a branch in their own worktree, such as brew/.wt-prod. memory brew-prod-backend
A session writes or updates a memory note when it learns a rule, a lesson or a decision, with the date and why. memory MEMORY.md
A Stop hook asks a session that changed brew, brand-directions or memory to run handbook-update before it ends. .claude/settings.jsonmemory brew-handbook
Reviews in QV rounds use fresh, independent reviewers, not anchored on the building session's view. memory brew-qv-process
Tomorrow
Item
Version
Tag
Memory notes, CLAUDE.md, AGENTS.md and skills as the shared context
v1
Stays
The handbook as the planning home; memory notes keep working truth and point here
v1
Changes
Sai and Arvind running their own Claude sessions on the same rules
v1
New, see Open
Old memory notes folded into handbook pages and archived
v2
Changes
How we do it
Start: read MEMORY.md, then the notes and handbook pages your task touches. For brew, read brew/CLAUDE.md, SCOPE.md and DUMMY.md.
Before planning, check the decisions log and the Open part of the pages you touch. Never re-decide a decided thing.
For phased work: write the plan, get Param's yes, and run a QV round after each phase.
Commit only your lines; push; deploy from a worktree:
Do Sai and Arvind run Claude sessions on brew? No source says. Proposal: yes, each in their own worktree on a branch, merging through Param until they have done one QV round with him.
Which memory notes move into the handbook? Proposal: rules and runbooks move into handbook pages over the next two weeks; memory notes then keep a one-line pointer.
