#34

2026-07-05 11:27:45 +09:00
@@ -129,13 +129,43 @@ pass or the remaining failure is clearly blocked.
 - Treat TSX formatting rules as hard constraints, not preferences. Before
  finishing a TSX edit, inspect the edited hunks for closing `)`, `]`, and `}`
  placement and fix violations instead of relying on formatter defaults.
+- After every TSX edit, perform a style-only self-review of the edited hunks
+  before running verification or reporting completion. The task is not complete
+  while any edited TSX hunk violates these local formatting rules.
+- The TSX self-review must classify every edited leading or trailing `)`, `]`,
+  and `}` by syntax role before deciding whether it is valid. Do not apply a
+  rule by glyph alone. A closing `)` for a function parameter list is different
+  from a closing `)` for a function call. A closing `}` for a block is different
+  from a closing `}` for an object, type literal, import list, or destructuring
+  pattern.
+- The TSX self-review must confirm there are no common Prettier-style React
+  component declarations with a multi-line destructured parameter.
+- The TSX self-review must confirm multi-line function declaration parameter
+  `)` placement follows the detailed parameter-list rules below.
+- The TSX self-review must confirm call-expression `)` is never at the
+  beginning of a line.
+- The TSX self-review must confirm object/type/import/destructuring `}` is not
+  at the beginning of a line.
+- The TSX self-review must confirm multi-line function/lambda/callback/block
+  `}` is on its own line and never at the end of the previous line.
+- The TSX self-review must confirm array `]` is not at the beginning of a line.
+- The TSX self-review must confirm JSX closing markers and closing parentheses
+  keep the surrounding compact style.
+- The TSX self-review must confirm leading indentation follows 4-space logical
+  indentation with tabs only as leading 8-space compression.
 - For long Tailwind `className` strings, wrap across lines only when needed.
 - Keep continuation indentation aligned with the 4-space logical indentation
  rule, using tabs only as leading 8-space compression.
 - In TypeScript and TSX function declarations, including `const` arrow
-  function declarations, when the parameter list spans multiple lines, always
-  put the closing parenthesis at the beginning of its own line before the return
-  type or `=>`. Do not put that closing `)` at the end of the previous line.
+  function declarations, classify the parameter list before placing the closing
+  `)`.
+- If the parameter list itself is given its own multi-line block after the
+  function's opening `(`, put the closing parameter `)` at the beginning of its
+  own line before the return type or `=>`.
+- If the only line break is inside a parameter's inline type, object type, or
+  destructuring shape, and the parameter list itself is not split as a separate
+  block, keep the closing parameter `)` on the same line as that parameter's
+  final `}`. In this case, moving `)` to a new line is wrong.
 - Do not write React component declarations in the common Prettier form
  `const Component = ({ ... }) => (` when the destructured parameter spans
  multiple lines. Use the project form with the opening `(` after `=`, the
@@ -162,8 +192,358 @@ pass or the remaining failure is clearly blocked.
  single physical line.
 - Always add braces around `if`, `else`, or `for` bodies when the body spans
  two or more physical lines, even if it is one statement.
+- Spell British English identifiers correctly when the feature name uses
+  British English. Use `Behaviour`, not `Behavior`, for new component and file
+  names unless editing an already established American-English API.
 - Avoid reformatting unrelated JSX.

+### Delimiter decision table
+
+Use this table before accepting any edited TypeScript or TSX hunk. The table is
+more authoritative than formatter habit.
+
+#### Import and export named bindings
+
+Bad:
+
+```ts
+import {
+    Button,
+    Card,
+} from '@/components/ui'
+```
+
+Good:
+
+```ts
+import { Button,
+	 Card } from '@/components/ui'
+```
+
+Also acceptable when short:
+
+```ts
+import { Button, Card } from '@/components/ui'
+```
+
+Rule: named-binding `}` is associative-array-style syntax. It must not be alone
+at the beginning of a line. Prefer keeping `{` with the first binding and `}`
+with the final binding when this fits the line limit.
+
+#### Type literals
+
+Bad:
+
+```ts
+type Props = {
+    open: boolean
+    onOpenChange: (open: boolean) => void
+}
+```
+
+Good:
+
+```ts
+type Props = {
+    open: boolean
+    onOpenChange: (open: boolean) => void }
+```
+
+Rule: type-literal `}` is not a block close. It must stay on the same line as
+the final property unless that would break the hard line limit.
+
+#### Object literals
+
+Bad:
+
+```ts
+const value = {
+    open,
+    activeScope,
+}
+```
+
+Good:
+
+```ts
+const value = {
+    open,
+    activeScope }
+```
+
+Bad:
+
+```ts
+const value = useMemo (() => ({
+    open,
+    activeScope,
+}), [open, activeScope])
+```
+
+Good:
+
+```ts
+const value = useMemo (() => ({
+    open,
+    activeScope }), [open, activeScope])
+```
+
+Rule: object-literal `}` is associative-array-style syntax. It must not be on a
+line by itself. Keep it with the final property, and keep call `)` off the
+beginning of a line.
+
+#### Destructuring parameters
+
+Bad:
+
+```tsx
+const Component: FC<Props> = ({
+    open,
+    onOpenChange,
+}) => {
+  return null
+}
+```
+
+Good:
+
+```tsx
+const Component: FC<Props> = (
+    { open,
+      onOpenChange },
+) => {
+  return null
+}
+```
+
+Rule: when a React component or helper takes a destructured object parameter
+that spans multiple lines, do not use the Prettier-style `= ({ ... }) =>`
+shape. Put the function parameter list on its own lines. The destructuring `}`
+stays with the final binding. The parameter-list `)` is then allowed and
+required at the beginning of its own line.
+
+#### Inline typed destructuring parameter
+
+Good:
+
+```ts
+const RouteTransitionWrapper = ({ user, setUser }: {
+    user:     User | null
+    setUser:  Dispatch<SetStateAction<User | null>> }) => {
+  return null
+}
+```
+
+Bad:
+
+```ts
+const RouteTransitionWrapper = ({ user, setUser }: {
+    user:     User | null
+    setUser:  Dispatch<SetStateAction<User | null>>
+}) => {
+  return null
+}
+```
+
+Rule: this is not a separately split parameter-list block. The line break is
+inside the inline type. Keep the type-literal `}` and parameter-list `)` on the
+same line as the final type property.
+
+#### Multi-line normal parameter list
+
+Bad:
+
+```ts
+const updateDraft = <Key extends keyof Settings,> (
+    key: Key,
+    value: Settings[Key]) => {
+  return null
+}
+```
+
+Good:
+
+```ts
+const updateDraft = <Key extends keyof Settings,> (
+    key:    Key,
+    value:  Settings[Key],
+) => {
+  return null
+}
+```
+
+Rule: when the parameter list itself is split across multiple parameter lines,
+the closing parameter `)` goes at the beginning of its own line before `=>` or
+the return type.
+
+#### Function and callback blocks
+
+Bad:
+
+```ts
+const handleSave = () => { save ()
+}
+```
+
+Bad:
+
+```ts
+const handleSave = () => {
+  save () }
+```
+
+Good:
+
+```ts
+const handleSave = () => {
+  save ()
+}
+```
+
+Rule: block `}` closes executable code, not associative data. Multi-line
+function, lambda, callback, `if`, `for`, `switch`, and similar block braces
+belong on their own line.
+
+#### Function and method calls
+
+Bad:
+
+```ts
+const value = compute (
+    first,
+    second
+)
+```
+
+Good:
+
+```ts
+const value = compute (
+    first,
+    second)
+```
+
+Rule: call-expression `)` must not be at the beginning of a line. The exception
+for leading `)` applies only to function declaration parameter lists, never to
+calls.
+
+#### JSX closing markers
+
+Bad:
+
+```tsx
+<Button
+    type="button"
+    onClick={handleSave}
+>
+  保存
+</Button>
+)
+```
+
+Good:
+
+```tsx
+<Button
+    type="button"
+    onClick={handleSave}>
+  保存
+</Button>)
+```
+
+Bad:
+
+```tsx
+<Input
+    value={value}
+    onChange={handleChange}
+/>
+```
+
+Good:
+
+```tsx
+<Input
+    value={value}
+    onChange={handleChange}/>
+```
+
+Rule: keep `>` or `/>` with the final prop, and keep JSX closing parentheses in
+the local compact form such as `</div>)`.
+
+#### Arrays and tuples
+
+Bad:
+
+```ts
+const items = [
+    first,
+    second,
+]
+```
+
+Good:
+
+```ts
+const items = [
+    first,
+    second]
+```
+
+Good when short:
+
+```ts
+const items = [first, second]
+```
+
+Rule: array and tuple `]` must not be at the beginning of a line. Keep it with
+the final element unless that would break the hard line limit.
+
+#### Single-line braces
+
+Good:
+
+```ts
+const next = { ...current, enabled: true }
+const tag = { id, name }
+```
+
+Bad:
+
+```tsx
+<Component prop={ value }/>
+```
+
+Good:
+
+```tsx
+<Component prop={value}/>
+```
+
+Rule: JavaScript object braces on one line get one inner space. JSX expression
+braces do not get inner spaces.
+
+#### Final TSX self-review checklist
+
+Before reporting completion after a TypeScript or TSX edit, check the edited
+hunks line by line:
+
+1. No import/export/type/object/destructuring `}` appears alone at the beginning
+   of a line.
+2. No call-expression `)` appears at the beginning of a line.
+3. Any leading `)` is definitely closing a function declaration parameter list,
+   not a call.
+4. Any parameter-list `)` at the end of a line is valid because the parameter
+   list itself was not split, only an inline type or destructuring shape was.
+5. No array or tuple `]` appears at the beginning of a line.
+6. Multi-line executable block `}` is on its own line.
+7. JSX `>` and `/>` stay with the final prop unless nearby code proves
+   otherwise.
+8. JSX closing parentheses keep the compact local style.
+9. Leading indentation is 4-space logical indentation with tabs used only as
+   leading 8-space compression.
+10. No line has trailing whitespace.
+
 ## Lint and build constraints

 - ESLint uses `@eslint/js`, `typescript-eslint`, `eslint-plugin-react-hooks`,