How we work
The agreements made so far. Anything marked suggested is an idea, not a decision.
The spec is canon
Planet_Spec_Sheet.md is canon for the world, mechanics and creatures. Production_Plan.md is canon for scope, team and schedule.[Locked] means decided and beats anything said in chat, found in code or written in another document. [Proposed] is a suggestion. The Native Life section is Locked by default unless a bullet says otherwise.- Anything the spec doesn't define is not canon. Don't invent lore, numbers or mechanics silently: write them down as
[Proposed] and ask. The spec has no gameplay parameters yet (drain rates, timers, damage), so tuning values are proposals.
- Cite spec sections by heading title, not by § number. The re-evaluation's Step 5 will renumber the spec.
- Changes to
[Locked] text are the design lead's call. In git they go through a pull request or the design lead's approval. In Claude Code, editing the spec file stops and asks first.
- A baseline commit (
774a78f) snapshots the docs from before that renumbering, so git diff 774a78f -- Planet_Spec_Sheet.md shows exactly what changed.
Git and LFS
- Binaries (images, models, audio, video, fonts, archives) go through Git LFS. The rules are in
.gitattributes and were set up before the first binary was committed.
- GitHub's free LFS quota is 10 GiB of storage and 10 GiB of bandwidth. At a $0 budget, going over blocks LFS for the rest of the month rather than billing.
- The repository is on GitHub as a private repo (
hansons/AllSystemsRed), and new teammates need to be added as collaborators. Claude Code never pushes without explicit confirmation.
- Documents and HTML pages made with Claude stay as local files in the repository, never published through Claude's own Artifact tool.
site/ is the exception by design: it's the project's actual website, deployed via Cloudflare Pages like any other file here.
How we track work
- Repo access is the whitelist. Being a collaborator on hansons/AllSystemsRed is what "on the team" means technically — there's no separate login system, and none is planned.
- Onboarding status lives in a GitHub issue, not this site. Open one from the Onboarding issue template and check items off there — that's what Winds looks at. The Start checklist on this site still exists, but it only unlocks the site for you, in this browser; it isn't visible to anyone else.
- Development tasks and due dates live on the repo's GitHub Project board, using GitHub's own assignee, status and due-date fields. Nothing here duplicates that.
Unity project rules
- The stack is Unity 6.3 LTS with URP, on PC. (
Production_Plan.md still says HDRP in three places; that's out of date and the correction is waiting on approval.)
- The project lives in
Game/ and is created once through Unity Hub, in an empty folder.
- Commit
.meta files. They hold each asset's GUID.
- Move and delete assets only inside the Unity Editor. Doing it outside breaks the GUID.
- Never hand-edit
.meta files, anything under Library/, or scene and prefab YAML.
- One person owns a scene at a time. Scene merges are painful, so prefer prefabs and additive scenes.
- Only one Unity process can open the project at a time.
Library/, Temp/, Logs/ and UserSettings/ are git-ignored.
Using Claude Code
- Right now Winds is the only Claude Code user. Code Claude writes reaches everyone else as ordinary commits, and gets reviewed like any other diff.
- Claude reads the shared instructions in
CLAUDE.md and .claude/settings.json when it opens in the folder. Those files are why it asks before editing the spec, and commits only when asked.
- Claude checks code by compiling and running tests, not by reading it. It can't judge how something feels, so the lightning-flash mechanic needs a human playtest.
- The dev environment diagram shows how Claude Code, Unity and the repo connect, and which pieces are still to come.
Generated 3D assets
- Automation options for 3D assets are candidates to test, not decisions. The pipeline diagram has each one, with links.
- Rights to a generated asset depend on the plan tier that made it: some free tiers are non-commercial or require credit. Keep a log of the tool, plan tier, input image and date for every generated asset (suggested; the log doesn't exist yet).
- Every asset, however it was made, gets a flash-lit test (dark scene, one hard light) and a playtest before it's accepted.
Terms you'll see
- Locked / Proposed
- Status tags on entries in the spec: decided versus suggested.
- Git LFS
- Stores large binary files outside normal git history; git keeps a small pointer instead.
- URP
- Unity's Universal Render Pipeline, the rendering setup this project uses.
- .meta file
- Unity's companion file for each asset, holding its GUID. Always committed.
- EditMode test
- A Unity test that runs in the Editor without entering Play Mode. It's how code is checked without a person watching.
- MCP
- Model Context Protocol: a bridge that lets Claude Code act on a running program such as the Unity Editor or Blender. Not set up yet.
- Flash-lit test
- Checking an asset in a dark scene with one hard light, because the game is lit mostly by lightning and meteor flashes.
- Provenance log
- A record of where each generated asset came from, so its rights can be checked later.
Open decisions (2026-09-21)
- Correct HDRP to URP in
Production_Plan.md.
- How new teammates get access to the private repo, and whether spec changes are enforced through pull requests (branch protection on private repos may need a paid plan; unverified).
- Which Unity MCP bridge to use, if any. It waits on the Unity licence tier.
- Whether to keep git or move to Unity Version Control. Revisit before Phase 2 art starts.
- The concept hand-off format with Guanacito, and whether an image-to-3D lane is adopted (to be tested once Unity is installed).