que01
e08af11b7d
Three of this task's defects were cross-layer wiring rather than logic, so they belong in the spec where the next session will read them, not only in the task's research notes. Frontend: a new client spec covering layer ownership (baseline is never written, preview hides rather than overwrites), why a handle carries only its id, why a handle's position must derive from the clamped value, the ban on computing inside a setState updater, and why per-pointermove React state is the wrong owner of per-frame feedback. Backend: the left/right convention now states the three places that must agree and why a sign convention can be wrong on both sides of the wire at once; a table of the four profile fields the geometry stage actually reads, so nobody builds UI for interval-scoped editing again before the compiler honours it; and the save-is-not-applying contract, including that compileFresh must be installed by every path that sets session.area. Also records that an identity test cannot catch an ignored editsFile, and that a regression test is only trustworthy once it has been seen to fail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1.4 KiB
1.4 KiB
Frontend Development Guidelines
Best practices for frontend development in this project.
Overview
This directory contains guidelines for frontend development. Fill in each file with your project's specific conventions.
Guidelines Index
| Guide | Description | Status |
|---|---|---|
| Direct Edit Client | Handle/ghost/preview layer ownership, drag projection, session and save contracts | Filled |
| Directory Structure | Module organization and file layout | To fill |
| Component Guidelines | Component patterns, props, composition | To fill |
| Hook Guidelines | Custom hooks, data fetching patterns | To fill |
| State Management | Local state, global state, server state | To fill |
| Quality Guidelines | Code standards, forbidden patterns | To fill |
| Type Safety | Type patterns, validation | To fill |
How to Fill These Guidelines
For each guideline file:
- Document your project's actual conventions (not ideals)
- Include code examples from your codebase
- List forbidden patterns and why
- Add common mistakes your team has made
The goal is to help AI assistants and new team members understand how YOUR project works.
Language: All documentation should be written in English.