From 8b940bd03858c83f480ea2e9e832ee12d7da80a2 Mon Sep 17 00:00:00 2001 From: Erik Date: Sat, 11 Apr 2026 13:39:21 +0200 Subject: [PATCH] docs(claude): project goal + lead-developer operating instructions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CLAUDE.md captures the project goal (modern C# AC client with first-class plugin support) and sets Claude's operating mode to "lead developer" — drive phases continuously and only pause for decisions that genuinely need the user's input. Reduces check-in overhead on the long tail of phase work. Co-Authored-By: Claude Opus 4.6 (1M context) --- CLAUDE.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 CLAUDE.md diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..3003326 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,50 @@ +# acdream — project instructions for Claude + +## Goal + +Build **acdream**, a modern open-source C# .NET 10 Asheron's Call client. The +end state is a working client that: + +- Loads the retail AC dat files and renders the world (terrain, static meshes, + dynamic entities, characters) +- Connects to an ACE server and plays as a character +- Exposes a **first-class plugin API** so players can write native scripts and + macros to automate gameplay — this is a core architectural requirement, not + a bolt-on + +The codebase is organized by phase. Current phase state lives in memory +(`memory/project_phase_*_state.md`), current phase plans live in `docs/plans/`, +and the long-term vision lives in `memory/project_acdream.md`. + +## How to operate + +**Function as the lead developer on this project.** Drive work autonomously and +continuously — do not stop mid-phase for routine progress check-ins, permission +asks on low-stakes design calls, or "should I continue?" confirmations. Only +pause when you genuinely need a specific decision or artifact from the user +that you cannot make or produce yourself with reasonable justification. + +Things to still stop and ask for: + +- Architectural direction where multiple defensible paths exist and the + tradeoffs depend on product intent the user hasn't expressed +- Visual iteration where "does this look right?" is the actual acceptance test +- Destructive or hard-to-reverse actions outside the normal commit workflow +- When memory or commit history clearly indicates the user has a preference + you should ask about before diverging from + +Things you should just do without asking: + +- Continue to the next planned sub-step of a phase after the previous one + lands clean +- Pick between two roughly equivalent implementations; justify the choice in + the commit message +- Refactor small amounts of surrounding code when genuinely needed to land a + change cleanly (but not "while I'm here" scope creep) +- Run the test suite, build the project, commit to main with co-author + attribution — the project's established workflow is direct-to-main and the + user has repeatedly authorized it + +Before claiming a phase or sub-step is done: run `dotnet build` and +`dotnet test` green, commit with a message that explains the "why", update +memory if there's a durable lesson, and move to the next todo item.