Project scaffold, agents and pipeline

Stand up the project, decide where state lives, and put the working practices in place before any feature is written.

Everything is local. No accounts, no server, no sharing, and no ambition to have any.

Nothing else on the board starts until this is done.

Acceptance criteria

The project

• Vite, React, TypeScript. Runs on npm ci && npm run dev with nothing else installed
• Node version pinned in .nvmrc
• A single store holds the event, the room config and the guest list
• State persists to local storage and survives a refresh
• Clearing storage returns the app to its first-visit state without an error
• Typecheck, lint and test scripts exist and pass on an empty project

AGENTS.md and docs

• AGENTS.md at the repo root, and docs/ holding the engineering standards
• AGENTS.md states plainly that the requirements for this product are not in this repo. They are in Tickety, over MCP, and an agent that does not go and get them is guessing
• It gives the traversal, in this order:
  • getJiraIssue on the ticket being worked
  • getJiraIssue on that ticket's parent, because the epic carries the definition of done and the ticket does not repeat it
  • getConfluencePage on every remoteLinks entry
  • getConfluencePage again on the relatedPages of those, which is one further hop
• It says to read the comments. Some tickets carry their only route onward in a comment rather than in a link
• It says a thin ticket is thin on purpose. Never invent an acceptance criterion, and never build ahead of the board. KB-1 lists what is deliberately out of scope
• It names the five agents below and says when to use each

Agents

Five, in .claude/agents/. The model is set explicitly on every one, because the default is inherit and an Opus session would otherwise spawn Opus subagents throughout.

• reviewer has no Write and no Edit. A reviewer that can edit quietly fixes what it finds, and then you have the fix instead of the finding
• tester is instructed not to read the module under test. A test written against the code tests what the code does rather than what it was supposed to do, and it will confirm a bug
• ui-developer and model-developer are split because the allocation engine is pure domain logic with no rendering. One agent doing both produces a solver that knows about React
• Planning runs on Opus and implementation on Sonnet. If a Sonnet agent cannot implement from the plan, tighten the plan rather than raising the model

Branches and commits

• Nothing is committed directly to main
• Every branch name carries the issue key: feat/TT-14-rules-engine
• Every commit message carries the issue key, first: TT-14: add the capacity rule
• Work that belongs to no ticket does not get committed

Pipeline

GitHub Actions, running on the Node version in .nvmrc.

• On pull request: install, typecheck, lint, test. A failure blocks the merge
• On merge to main: the same checks run again, and only then is a version applied
• A semantic version tag is created on merge. The first is v0.1.0
• Each later merge bumps the minor version. It never reuses or skips a tag, and re-running the workflow on the same commit does not produce a second one
• The tag is pushed and a GitHub release is created against it

Notes

Build this first and nothing after it needs retrofitting. TT-7 is second.

The version bump is minor per merge rather than read from commit messages, because the commit format here leads with the issue key rather than a conventional-commit type.

A commit-msg hook is the cheapest way to make the issue key rule real rather than aspirational.