Project Buddies is a personal website that teaches Blender through each user's own projects. A project collects goals, milestones, progress and preferences in shared memory. Each project chat pairs that project with one buddy: a character with its own written voice. A separate central chat lets the user explore an idea without choosing or creating a project. The tutor searches the official Blender Reference Manual and cites the sections it uses. The site runs on Vercel. Owner: Axlog.

These criteria define the product, not a claim that production validation is complete:

• Invited users sign up with an invite code and email, then sign in by an emailed link. Protected pages and API routes require a session (passphrase-gated-email-sign-in).
• Each user's data is private, with a $5 monthly Claude quota (private-user-data, claude-spend-quota).
• Creating a project starts an interview chat that writes goals and milestones to project memory.
• A project chat uses the chosen project and buddy, receives the project's memory, and can be reopened. Built-in buddies are Hippy, Mr. Tee, Fjord Tines, Span Tines, Argon Sprangler and Roland Dustchain (persona-spoof-names).
• Users can clone and edit buddies as text (personas-as-text).
• The tutor searches the latest stable manual; factual Blender claims cite real manual sections. The indexed branch lives in apps/web/src/manual/manual-source.ts, and one command rebuilds the index for a new stable release.
• The tutor updates project memory during chats. The user can view, edit and undo changes.
• Haiku names chats until the user renames them (haiku-chat-names).
• Every use case in apps/web/use-cases/ has a passing test.

The central chat and its optional create_project tool are described in central-chat. It has no project memory and creates no project unless the user asks.

• Rules: the repo's AGENTS.md; design choices and rejected alternatives are in Decisions.
• Commands: the repo's README.md; additional observations are in Site operations.
• Work and status: GitHub issues. This page is not a second backlog.
• Implementation: the issue pipeline. A merge to integration deploys a preview only. Production releases are manual, through scripts/deploy.sh and the release workflow (integration-branch, release-workflow).
• Decisions: choices, failed gates and rule conflicts go to Axlog with options and a recommendation. Record rulings with their date and rejected alternatives.
• Safety: agents must never connect to the production database, print a .env* file or run real Claude. Production, Preview and Development share one Neon database; tests use a separate database and the mock tutor.

The retired plan left production-check-after-merge unresolved: should production get a cheap check after each merge, or only a maintainer-run real-Claude smoke test? Automatic per-merge production releases have since been replaced by manual releases. The release workflow's smoke test covers signed-out requests only; it does not validate tutor replies or prompt caching.

personas-and-prompts-rulings calls for each release's smoke test to record cacheRead and cacheWrite for an edited buddy. Issue #37 records the proposed real-Claude and theme checks, including watching for short citing steps and uncited step-limit answers. It was closed after pipeline triage rejected it as maintainer-only release work, not as evidence that the checks passed. The sources reviewed for this cleanup do not establish that the validation gap is resolved.

Axlog retired the staged working plan on 2026-10-12 in favour of GitHub issues and the repo's docs. This replaced delegated-staged-build. The old process is summarised in How the build runs, with lessons in Retrospectives. Stage briefs, reports, diffs and screenshots were kept in ../project-buddy-worktrees/ (<stage>-briefs/ and <stage>-*.md); these are historical local paths, not required checkout contents.