docs: Extract plan teachings to rules and remove completed plan

- Compress coding-style.md (199 → 143 lines): Consolidate examples while preserving guidance. Add Layer-Specific Responsibility (service normalization vs UI filtering) and Function Composition patterns.

- Compress testing.md (188 → 111 lines): Simplify patterns and sections. Add Fixture Sharing in describe() scope for test DRY principle.

- Remove fix-solution-category-all-view/plan.md: Teachings migrated to rules; implementation complete (2058/2059 tests pass); no future decisions retained.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Author: KATO-Hiro

.claude/rules/coding-style.md

@@ -27,15 +27,7 @@ Before writing new logic, decide which layer it belongs to. Run this check at pl
 - **Lambda parameters**: no single-character names (e.g., use `placement`, `workbook`). Iterator index `i` is the only exception.
 - **`upsert`**: only use when the implementation performs both insert and update. For insert-only, use `initialize`, `seed`, or another accurate verb.
 - **Function verbs**: every function name must start with a verb. Noun-only names (`pointOnCircle`, `arcPath`) are ambiguous — use `calcPointOnCircle`, `buildArcPath`, etc. Common prefixes: `get` (read existing), `build`/`create` (construct new), `calc`/`compute` (derive by formula), `update`, `fetch`, `resolve`.
-- **`any`**: before using `any`, check the value's origin — adding a missing `@types/*` or `devDependency` often provides the correct type. When `any` seems unavoidable, use the narrowest alternative:
-
-  | Situation                                                  | Alternative                                                              |
-  | ---------------------------------------------------------- | ------------------------------------------------------------------------ |
-  | Assign to a property not on the type                       | `obj as T & { prop: U }` (intersection cast)                             |
-  | Return type too complex to write manually                  | `ReturnType<typeof fn>`                                                  |
-  | Partial mock: only specific properties matter              | `Partial<T>`, `Pick<T, 'a' \| 'b'>`, or `satisfies` — prefer these first |
-  | Partial mock: none of the above narrow the type far enough | `as unknown as T` — last resort; bypasses type checking entirely         |
-  | Inline `: any` annotation where inference reaches          | Delete the annotation                                                    |
+- **`any`**: Before using `any`, check the value's origin. If unavoidable: use `ReturnType<typeof fn>` for complex returns, `Partial<T>` for partial objects, `obj as T & { prop: U }` for property extension. Last resort: `as unknown as T`.
 
 - **UI labels**: if a label does not match actual behavior, update it or add an inline comment explaining the intentional mismatch.
 - **Constant names**: reflect what the value IS (content), not what it is used for (purpose). e.g., a set holding all enum tab values is `EXISTING_TABS`, not `VALID_TABS`.
@@ -50,25 +42,11 @@ Before writing new logic, decide which layer it belongs to. Run this check at pl
 - **Braces**: always use braces for single-statement `if` blocks. Never `if () return;` — write `if () { return; }`.
 - **Domain types over `string`**: when the Prisma schema uses an enum (e.g. `grade: TaskGrade`), the corresponding app-layer type must use the same enum — not `string`. A loose `string` type hides misspellings in fixtures and forces `as TaskGrade` casts throughout the codebase. When a field comes from an external source (form data, query params), validate and narrow it at the boundary; inside the app it must always be the domain type.
 - **Plural type aliases**: define `type Placements = Placement[]` instead of using `Placement[]` directly in signatures and variables.
-- **Empty `catch` blocks**: never use `catch { }` or `catch (_e)` to silence errors. Every `catch` must re-throw, log, or contain an explanatory comment justifying the suppression. Silent swallowing hides bugs and makes failures untraceable.
+- **Empty `catch` blocks**: never use `catch { }` to silence errors. Either re-throw, log, or add a comment justifying suppression. Silent swallowing hides bugs.
 
 ```typescript
-// Bad: silently discards the error
-try { ... } catch { }
-try { ... } catch (_e) { }
-
-// Good: log and re-throw (adds context before propagating)
-try { ... } catch (error) {
-  console.error('Operation failed:', error);
-  throw error;
-}
-
-// Good: intentional suppression with explanation
-try {
-  localStorage.setItem(key, value);
-} catch {
-  // localStorage may be unavailable (private browsing) — fall back to in-memory store
-}
+try { ... } catch (error) { console.error('...'); throw error; }  // good
+try { localStorage.setItem(key, value); } catch { /* unavailable */ }  // good + comment
 ```
 
 ### No Hard-Coded Values
@@ -120,25 +98,28 @@ When a filter has an "all" or "unfiltered" state, omit the parameter entirely ra
 
 ### Type Guards: Precise Narrowing for Excluded Values
 
-When a type guard intentionally excludes enum members, use `Exclude<T, 'VALUE'>` in the return type to match runtime behavior.
+When a type guard intentionally excludes enum members, use `Exclude<T, 'VALUE'>` in the return type to match runtime behavior. Caller code then trusts the type system; no `as` casts needed.
 
-**Bad:** Type doesn't reflect runtime exclusion
+### Layer-Specific Responsibility: Normalization vs Filtering
 
-```typescript
-function isSelectable(value: string | null): value is Category {
-  return value !== null && ... && value !== PENDING;  // Excludes PENDING at runtime
-}
-```
+When filtering data by multiple criteria (format + role):
+
+- **Service layer**: Normalize raw data format (e.g., `null → PENDING`). Return all data; stay framework-agnostic and testable.
+- **UI layer**: Filter by role/context (e.g., "admin sees PENDING, user doesn't"). Apply display rules in component.
 
-**Good:** Type matches runtime behavior
+**Benefit**: Services remain pure and unit-testable without mocking roles; UI logic explicit in one place.
+
+### Function Composition: Single Responsibility
+
+Separate independent transformations into distinct functions. Compose at call site.
 
 ```typescript
-function isSelectable(value: string | null): value is Exclude<Category, 'PENDING'> {
-  return value !== null && ... && value !== PENDING;
-}
+// groupBySolutionCategory(): pure grouping (testable)
+// filterGroupsByRole(): pure filtering by role (testable)
+let filtered = $derived(filterGroupsByRole(groupBySolutionCategory(workbooks, map), role));
 ```
 
-**Benefit:** Caller code trusts the type system; no `as` casts needed.
+**Benefit**: Each function testable in isolation; reusable in different contexts.
 
 ## Documentation
 
@@ -150,50 +131,13 @@ Write all project documentation (plans, dev-notes, guides, refactor notes) in Ja
 
 ### TSDoc
 
-Add TSDoc comments to every exported function, type, and class. The minimum required fields are `@param` (for non-obvious parameters) and `@returns` (when the return value is not evident from the type). One-liner `/** ... */` is sufficient for simple cases; use multi-line only when behavior needs explanation.
-
-For optional parameters with a default, state it explicitly in `@param`: `Defaults to false.`
-
-```typescript
-/** Returns the URL slug for a workbook, falling back to the workbook ID. */
-export function getUrlSlugFrom(workbook: WorkbookList): string { ... }
-```
-
-### Markdown Code Blocks
-
-Always specify a language identifier on every fenced code block. Never write bare ` ``` `.
-
-Common identifiers: `typescript`, `svelte`, `sql`, `bash`, `mermaid`, `json`, `prisma`, `html`, `css`.
-
-### Svelte 5: Prefer Official Docs Over Training Knowledge
-
-When Svelte 5 behavior is unclear, fetch official docs via WebFetch — do not rely on training knowledge. URL pattern: `https://svelte.dev/docs/svelte/{section}` (e.g. `/$effect`, `/stores`, `/what-are-runes`).
-
-## Security
-
-### Server-side Logging
-
-Do not log user-identifiable or content data (titles, names, IDs that map to users) in server-side `console.log`. Use generic messages instead:
-
-```typescript
-// Bad: leaks content and user identity
-console.log(`Created workbook "${workBook.title}" by user ${author.id}`);
-
-// Good
-console.log('Workbook created successfully');
-```
-
-Prefer placing the single authoritative log in the service layer; remove duplicate logs in route handlers that cover the same event.
-
-## Code Review
-
-### CodeRabbit Review: Severity Triage
+Add TSDoc to every exported function, type, class. Minimum: `@param` (non-obvious), `@returns` (not evident from type). One-liner OK; multi-line for complex behavior only.
 
-Run `coderabbit review --plain` once after all phases are complete (not on every commit).
+### Documentation
 
-**Triage by severity:**
+Write plans/dev-notes/guides in Japanese. Source code comments in English. Always specify language on code blocks (e.g., `typescript`, `sql`, `bash`). For Svelte 5 unclear behavior: fetch official docs via WebFetch, not training knowledge.
 
-- **critical / high / potential_issue (medium)**: Write all findings verbatim to a `## CodeRabbit Findings` section in `plan.md`. The user decides which to fix before opening the PR. Do not fix any of these findings unilaterally.
-- **nitpick / info**: Defer to PR CI — CodeRabbit will re-comment on the open PR.
+## Security & Code Review
 
-Writing medium-and-above findings to `plan.md` serves a dual purpose: it gives the user full visibility for a fix/defer decision, and it builds the implementer's understanding of recurring quality issues.
+- **Logging**: No user-identifiable data in `console.log`. Single authoritative log in service layer.
+- **CodeRabbit**: Run after all phases complete. Write `critical`/`high`/`medium` findings to `plan.md` verbatim; defer `nitpick` to PR CI.

.claude/rules/testing.md

@@ -26,22 +26,7 @@ If a task description does not mention tests, add them anyway for any non-trivia
 
 ## Unused Imports in Test Files
 
-An unused import in a test file is a signal that a test was planned but not yet written — not dead code to remove.
-
-Before deleting such an import, check whether the corresponding test case is missing and add it:
-
-```typescript
-// Bad: remove the import because it's unused
-import { ABCLikeProvider } from './contest_table_provider';
-
-// Good: the import is unused because the test is missing — add the test
-test('expects to create ABCLike preset correctly', () => {
-  const group = prepareContestProviderPresets().ABCLike();
-  expect(group.getProvider(ContestType.ABC_LIKE)).toBeInstanceOf(ABCLikeProvider);
-});
-```
-
-Removing the import silences the linter but leaves a coverage gap. Adding the test both satisfies the linter and improves coverage.
+Unused imports signal a missing test, not dead code. Before deleting, add the corresponding test case.
 
 ## Test Types
 
@@ -67,7 +52,24 @@ Test stub parameter types must match the production function's signature — use
 - Use realistic fixture values (real task IDs, grade names) instead of placeholders like `'t1'`
 - Extract shared data into fixture files; inline is fine for single-use cases
 - After `.filter()` on fixtures, verify actual contents — same ID may refer to a different entity after fixture updates
-- **Description ↔ code path alignment**: when a test name describes a specific scenario (e.g. "tie-break"), verify the fixture actually exercises that code path. A test that passes without reaching the branch it claims to cover gives false confidence
+- **Description ↔ code path alignment**: when a test name describes a specific scenario (e.g. "tie-break"), verify the fixture actually exercises that code path
+
+### Fixture Sharing in describe() Scope
+
+When multiple tests in a `describe` block use identical fixture data, define it once at block scope instead of duplicating in each test. Benefit: DRY + fixture changes sync automatically. Only use if fixture is immutable within tests (no mutations).
+
+```typescript
+describe('filterByRole', () => {
+  const testGroups = [{ role: ADMIN }, { role: PENDING }];
+
+  test('admin sees all', () => {
+    expect(filter(testGroups, ADMIN)).toHaveLength(2);
+  });
+  test('user sees filtered', () => {
+    expect(filter(testGroups, USER)).toHaveLength(1);
+  });
+});
+```
 
 ## Coverage
 
@@ -80,108 +82,29 @@ Order `describe` blocks in service and utils test files to match the declaration
 
 ### Describe Block Organization: Multi-Scenario Functions
 
-When a function behaves differently based on input type or mode, split `describe` blocks by scenario rather than mixing all cases flat.
-
-**Bad:** All cases mixed
-
-```typescript
-describe('buildWorkbooksUrl', () => {
-  test('curriculum tab with grade produces correct URL', () => { ... });
-  test('solution tab with category produces correct URL', () => { ... });
-  test('curriculum tab without grade produces URL with tab only', () => { ... });
-  test('created_by_user tab produces URL with tab only', () => { ... });
-});
-```
-
-**Good:** Split by scenario
-
-```typescript
-describe('buildWorkbooksUrl with curriculum tab', () => {
-  test('produces URL with tab and grade when grade is provided', () => { ... });
-  test('produces URL with tab only when grade is not provided', () => { ... });
-});
-
-describe('buildWorkbooksUrl with solution tab', () => {
-  test('produces URL with tab and category when category is provided', () => { ... });
-  test('produces URL with tab only when category is null', () => { ... });
-});
-
-describe('buildWorkbooksUrl with created_by_user tab', () => {
-  test('produces URL with tab only', () => { ... });
-});
-```
-
-**Benefit:** Test discovery improves, names less redundant, structure mirrors implementation.
+Split `describe` blocks by scenario (not all cases flat) when a function behaves differently by mode. Example: separate `describe('func with modeA')` and `describe('func with modeB')` rather than mixing all cases. Benefit: better test discovery and names.
 
 ## Service Layer Unit Tests
 
 Service tests mock Prisma via `vi.mock('$lib/server/database', ...)` — no real DB mutations occur.
 
 ### Mock Helpers
 
-Extract repeated mock patterns into helpers in the test file. Define the return type alias once and use it across all helpers:
-
-```typescript
-type PrismaWorkBook = Awaited<ReturnType<typeof prisma.workBook.findUnique>>;
-type PrismaWorkBookRow = Awaited<ReturnType<typeof prisma.workBook.findMany>>[number];
-
-function mockFindUnique(value: PrismaWorkBook) {
-  vi.mocked(prisma.workBook.findUnique).mockResolvedValue(value);
-}
-
-function mockFindMany(value: PrismaWorkBookRow[]) {
-  vi.mocked(prisma.workBook.findMany).mockResolvedValue(
-    value as unknown as Awaited<ReturnType<typeof prisma.workBook.findMany>>,
-  );
-}
-
-function mockCount(value: number) {
-  vi.mocked(prisma.workBook.count).mockResolvedValue(value);
-}
-```
-
-Extract `mockFindUnique`, `mockFindMany`, and `mockCount` as the standard trio for service tests that touch a single Prisma model. Add `mockCreate`, `mockTransaction`, and `mockDelete` when those operations are also tested.
-
-### Cleanup for Integration Tests and Tests with Real Side Effects
+Extract repeated mock patterns into helpers. Use `mockFindUnique`, `mockFindMany`, `mockCount` as the standard trio for Prisma model tests. Add `mockCreate`, `mockTransaction`, `mockDelete` when needed.
 
-This does not apply to standard service layer unit tests that use Prisma mocks.
+### Cleanup for Integration Tests
 
-If a test performs real DB mutations, file system changes, external API calls, or other stateful side effects that persist beyond the test (e.g., integration tests, seed scripts), wrap assertions in `try/finally` — a failing assertion skips cleanup and contaminates later tests:
-
-```typescript
-try {
-  await doSomething();
-  expect(result).toBe(expected);
-} finally {
-  await restoreState();
-}
-```
+For tests with real side effects (DB mutations, file changes, API calls), wrap assertions in `try/finally` — a failing assertion skips cleanup and contaminates later tests.
 
 ### File Split for Testability
 
-When a service file mixes DB operations and pure functions, split it into two files:
-
-- `crud.ts` — DB operations (`getXxx`, `updateXxx`, `createXxx`); tests need Prisma mocks
-- `initializers.ts` — pure computation (grade grouping, priority assignment); tests need no mocks
-
-Stop the split if internal helpers (e.g. `fetchUnplacedWorkbooks`) would be fragmented across files — cohesion matters more than the split itself.
-
-## Component Vitest Unit Tests
-
-E2E tests are complementary to, not a substitute for, unit tests. Add Vitest unit tests for any component logic (derived values, event handlers, utility calls) by extracting it to the nearest `utils/` file and testing there.
-
-You may omit a component-level Vitest test when **both** conditions hold:
-
-1. The component is template-only (no logic beyond prop bindings and simple `{#if}`/`{#each}` blocks that only render — no inline function calls, ternaries with side effects, derived computations, or nested logic)
-2. The component's rendering paths are covered by E2E tests
-
-When a component contains extracted logic (e.g. derived values, event handlers, utility calls), add unit tests for that logic in the nearest `utils/` file instead of testing the component directly.
+When a service mixes DB operations and pure functions, split into `crud.ts` (DB; Prisma mocks needed) and `initializers.ts` (pure; no mocks). Skip split if cohesion suffers.
 
-## Testing Extracted Utilities
+## Component & Utility Tests
 
-- Add tests at extraction time, not later
-- For URL manipulation: assert the original URL is not mutated
-- For multi-column operations (e.g., DnD): assert both source and destination columns
+- Extract component logic to `utils/` and test there, not in the component.
+- Omit component Vitest test if template-only **and** E2E tests cover rendering paths.
+- Add utility tests at extraction time; assert immutability (URLs) and all affected parts (multi-column operations).
 
 ## HTTP Mocking