[Feature] 同じ問題が複数のコンテストで使用されている場合でも表示できるようにしましょう

[KATO-Hiro]

Note

• problems ページを優先

Pending

• workbooks ページは、AtCoder Problems と同等の仕様
• アプリでcontest と task を関連づけるデータを投入する改修 <<< DBにCSV経由でデータを投入で十分
  • 1回データを投入したら基本的に更新しない
  • APIの取得や管理者画面の作成よりも、別の機能に工数を割くのが現実的

TODO

• 改修の影響範囲の特定
  • バックエンド
  • フロントエンド
• バックエンド
  • CRUDの実装
  • 上記のCRUDを使って、既存の関数・クラスを置き換え
  • seed.ts に コンテストと問題情報を関連づけた情報を追加できるようにする
  • サンプルデータの追加
  • 互換性を保つための関数・クラスを用意
• フロントエンド
  • 互換性維持のための関数・クラスを利用して、既存の実装を修正
  • 新しいデータ型に修正
• 動作確認
• 単体テストの追加・更新
• 動作確認できたら、使わなくなったデータ型・関数・クラスを削除
• テーブルを用意
  • 鉄則本
  • 数学・アルゴ本
• データの投入
  • 検証用環境
  • 本番環境
• データの投入を管理者画面から実行できるようにする

[KATO-Hiro]

WHAT

ProblemsのTableに関するソースコードとPairs of Contests and Problems APIを確認するとよさそうです。

See

https://github.com/KATO-Hiro/AtCoderProblems/blob/master/atcoder-problems-frontend/src/api/APIClient.ts
https://kenkoooo.com/atcoder/resources/contest-problem.json

[KATO-Hiro]

Contest-Problem Mapping Extension Plan

概要

既存のTask テーブルのunique制約を維持しながら、複数コンテストで同一問題を扱うための拡張方針を検討。AtCoder Problems の実装を参考に、段階的な移行戦略を策定。

現状の課題

課題1: Task識別の制限

• 問題: task_id が同じでも contest_id が異なるケースが多数存在
• 制約: Task テーブルの task_id unique制約は必ず維持する必要がある
• 影響: AtCoder Problems API の Problems API で登録済みの (task_id, contest_id) の問題のみ処理可能

課題2: 影響範囲の調査

• 数万行のTypeScript・Svelteコード
• map<string, TaskResult> 形式の処理が広範囲に存在
• e2eテストがほぼ実装されていないので、手動での確認が必要

解決方針

基本アプローチ

AtCoder Problems API を活用:

• 問題情報: 同一の task_id が存在する場合は、どれか一つのコンテストに割り当て
  • https://kenkoooo.com/atcoder/resources/problems.json
• コンテストと問題idの対応関係を網羅
  • https://kenkoooo.com/atcoder/resources/contest-problem.json

技術的解決策

1. 複合キーによる識別

方針: map<pair<string, string>, TaskResult> への移行

// 型定義
type TaskKey = `${string}:${string}`; // "contest_id:task_id"

// ヘルパー関数
function createTaskKey(contestId: string, taskId: string): TaskKey {
  return `${contestId}:${taskId}`;
}

// マップの型
type TaskResultMap = Map<TaskKey, TaskResult>;

利点:

• 文字列連結は一般的で高速
• TypeScriptのTuple型も利用可能だが、文字列の方が実用的
• O(1)での参照が可能

2. データマイグレーション戦略

// 既存データの移行
function migrateExistingData(oldMap: Map<string, TaskResult>): Map<TaskKey, TaskResult> {
  const newMap = new Map<TaskKey, TaskResult>();

  for (const [taskId, result] of oldMap) {
    const primaryContestId = result.contest_id || 'primary';
    const key = createTaskKey(primaryContestId, taskId);
    newMap.set(key, result);
  }

  return newMap;
}

// 互換性レイヤー
export class TaskMapAdapter {
  constructor(
    private enhanced: EnhancedTaskMap,
    private legacy: LegacyTaskMap,
  ) {}

  get(taskId: string, contestId?: string): TaskResult | undefined {
    if (contestId) {
      return this.enhanced.get(createTaskKey(contestId, taskId));
    }
    return this.legacy.get(taskId);
  }
}

3. インポート処理の分離

方針: 問題データインポートとマッピングデータインポートを別ページで処理

interface ImportOptions {
  includeContestMapping?: boolean; // contest-problem.json を使用
  onlyProblems?: boolean; // problems.json のみ使用
}

// 問題データインポート（既存制約を守る）
async function importTaskData(options: ImportOptions = {}) {
  if (options.onlyProblems !== false) {
    await importFromProblemsJson();
  }

  if (options.includeContestMapping) {
    await importContestProblemMapping();
  }
}

分離理由:

• 責務の分離（異なるAPIエンドポイント）
• エラーハンドリングの違い
• 将来のコンテストサイト固有設定への対応

実装計画

Phase 1: 基盤整備

• 新しい型定義の作成
• ユーティリティ関数の実装
• 互換性レイヤーの作成

Phase 2: 影響範囲調査

# 調査用コマンド
grep -r "taskId" src/ --include="*.ts" --include="*.svelte"
grep -r "Map<string," src/ --include="*.ts"
grep -r "TaskResult" src/ --include="*.ts"

Phase 3: 段階的移行

1. 新しい型定義を導入
2. 互換性レイヤーで既存コードをラップ
3. モジュール単位で新しいAPIに移行
4. テストで検証

Phase 4: インポート機能拡張

• マッピングデータ用の管理画面作成
• フィルタリング機能の実装
• バリデーション機能の追加

データ投入方法

推奨アプローチ: 管理者向けWebインターフェース

実装コスト: 14-21時間（目安）

// 基本機能
interface MappingImportPage {
  importContestProblemMapping(filters: ImportFilter): Promise<void>;
  previewMappingChanges(): Promise<MappingPreview>;
  validateMappingData(): Promise<ValidationResult>;
}

interface ImportFilter {
  contestIds?: string[];
  taskIds?: string[];
  dateRange?: { from: Date; to: Date };
}

利点:

• 長期的な保守性
• エラーハンドリングの容易さ
• 他コンテストサイト対応への拡張性

ディレクトリ構成案

src/routes/admin/import/
├── problems/           # 問題データインポート
│   ├── +page.svelte
│   └── types.ts
├── mapping/            # コンテスト-問題マッピング
│   ├── +page.svelte
│   ├── bulk/
│   └── selective/
└── shared/            # 共通コンポーネント
    ├── ImportStatus.svelte
    └── ValidationResults.svelte

今後の課題

短期

• 影響範囲の詳細調査
• プロトタイプの作成
• 基本的なe2eテストの追加

中期

• 他コンテストサイトAPI対応
• APIレート制限への対応
• UI/UXの改善

長期

• 完全自動化システム
• 包括的なテストスイート
• パフォーマンス最適化

リスク要因と対策

リスク	影響度	対策
既存機能の破綻	高	互換性レイヤーの実装
データ不整合	中	バリデーション強化
パフォーマンス劣化	中	段階的な最適化
メンテナンスコスト増	中	ドキュメント整備

決定事項

1. Task テーブルのunique制約は維持
2. 複合キー (contest_id:task_id) による識別
3. 段階的移行による安全な実装
4. インポート機能の責務分離
5. Web UI による管理画面実装

参考リンク

• API client in AtCoder Problems
• Problems API
• Contest-Problem API

---

作成日: 2025-09-17
最終更新: 2025-09-17
ステータス: 計画段階

[KATO-Hiro]

Contest-Task Pair Mapping 実装計画

概要

既存の Task テーブルの unique 制約を維持しながら、複数コンテストで同一問題を扱うための拡張実装計画。前回計画をベースに、互換性レイヤを用いた段階的移行戦略を詳細化。

討議内容の要約

1. 命名の決定

• モデル名: ContestTaskPair (「ペア」であることを明示)
• 型名: ContestTaskPairKey (Prisma モデルとの衝突回避)
• マップ型: TaskResultByContestTaskPair (キーと値の関係を明示)

2. データベース設計

Prisma スキーマ追加

model ContestTaskPair {
  id             String   @id @default(uuid())
  contestId      String
  taskTableIndex String
  taskId         String
  createdAt      DateTime @default(now())
  updatedAt      DateTime @updatedAt

  @@unique([contestId, taskId]) // ペアの重複を防止
  @@index([contestId])          // contestId 検索を高速化
  @@map("contesttaskpair")
}

設計判断:

• id 属性追加: 将来のリレーション対応・一貫性のため
• 複合一意制約: ペアレベルでの重複防止
• インデックス: 後から追加可能だが contestId 検索の高速化

マイグレーション

# 開発環境
pnpm dlx prisma migrate dev --name create_contest_task_pair

3. 型定義の更新

// 型定義
type ContestTaskPairKey = `${string}:${string}`; // "contest_id:task_id"

// ヘルパー関数
function createContestTaskPairKey(contestId: string, taskId: string): ContestTaskPairKey {
  return `${contestId}:${taskId}`;
}

// マップの型（明示的）
type TaskResultByContestTaskPair<T> = Map<ContestTaskPairKey, T>;

4. 互換性レイヤ（TaskResultMapAdapter）

目的: 既存コードを壊さずに段階的に新形式へ移行

class TaskResultMapAdapter<T> {
  constructor(
    private legacyMap?: Map<string, T>, // 既存: taskId -> value
    private enhancedMap?: Map<TaskResultByContestTaskPair, T>, // 新形式: contestId:taskId -> value
  ) {}

  private makeKey(contestId: string, taskId: string): ContestTaskPairKey {
    return `${contestId}:${taskId}`;
  }

  has(taskId: string, contestId?: string): boolean {
    // enhanced を優先、なければ legacy にフォールバック
    if (contestId && this.enhancedMap) {
      return this.enhancedMap.has(this.makeKey(contestId, taskId));
    }
    if (this.legacyMap && this.legacyMap.has(taskId)) return true;
    if (this.enhancedMap) {
      for (const key of this.enhancedMap.keys()) {
        if (key.endsWith(`:${taskId}`)) return true;
      }
    }
    return false;
  }

  get(taskId: string, contestId?: string): T | undefined {
    if (contestId && this.enhancedMap) {
      const v = this.enhancedMap.get(this.makeKey(contestId, taskId));
      if (v !== undefined) return v;
    }
    if (this.legacyMap && this.legacyMap.has(taskId)) {
      return this.legacyMap.get(taskId);
    }
    if (this.enhancedMap) {
      for (const [key, value] of this.enhancedMap) {
        if (key.endsWith(`:${taskId}`)) return value;
      }
    }
    return undefined;
  }

  // write-through を採用（移行期間の整合性確保）
  set(taskId: string, value: T, contestId?: string): void {
    if (this.legacyMap) this.legacyMap.set(taskId, value);
    if (contestId && this.enhancedMap) {
      this.enhancedMap.set(this.makeKey(contestId, taskId), value);
    }
  }

  delete(taskId: string, contestId?: string): boolean {
    let ok = false;
    if (contestId && this.enhancedMap) {
      ok = this.enhancedMap.delete(this.makeKey(contestId, taskId)) || ok;
    }
    if (this.legacyMap) {
      ok = this.legacyMap.delete(taskId) || ok;
    }
    return ok;
  }
}

5. 主要な変更箇所

src/lib/utils/task_results.ts への追加（新規ファイル）

// TaskMapAdapter の実装
type ContestTaskPairKey = `${string}:${string}`;
type TaskResultByContestTaskPair<T> = Map<ContestTaskPairKey, T>;

export class TaskMapAdapter<T> {
  constructor(
    private legacyMap?: Map<string, T>,
    private enhancedMap?: TaskResultByContestTaskPair<T>,
  ) {
    // 型チェック・assert
    console.assert(legacyMap || enhancedMap, 'At least one map must be provided');

    if (process.env.NODE_ENV === 'development') {
      console.log(
        `TaskMapAdapter initialized: legacy=${legacyMap?.size ?? 0}, enhanced=${enhancedMap?.size ?? 0}`,
      );
    }
  }

  get(taskId: string, contestId?: string): T | undefined {
    console.assert(
      typeof taskId === 'string' && taskId.length > 0,
      'taskId must be non-empty string',
    );

    const start = performance.now();

    if (contestId && this.enhancedMap) {
      const key = this.makeKey(contestId, taskId);
      const result = this.enhancedMap.get(key);
      if (result !== undefined) {
        if (process.env.NODE_ENV === 'development') {
          console.log(
            `TaskMapAdapter.get: enhanced hit (${(performance.now() - start).toFixed(2)}ms)`,
          );
        }
        return result;
      }
    }

    if (this.legacyMap && this.legacyMap.has(taskId)) {
      const result = this.legacyMap.get(taskId);
      if (process.env.NODE_ENV === 'development') {
        console.log(`TaskMapAdapter.get: legacy hit (${(performance.now() - start).toFixed(2)}ms)`);
      }
      return result;
    }

    // enhanced スキャン（移行期間のみ）
    if (this.enhancedMap) {
      for (const [key, value] of this.enhancedMap) {
        if (key.endsWith(`:${taskId}`)) {
          if (process.env.NODE_ENV === 'development') {
            console.log(
              `TaskMapAdapter.get: enhanced scan hit (${(performance.now() - start).toFixed(2)}ms)`,
            );
          }
          return value;
        }
      }
    }

    return undefined;
  }

  private makeKey(contestId: string, taskId: string): ContestTaskPairKey {
    console.assert(
      typeof contestId === 'string' && contestId.length > 0,
      'contestId must be non-empty string',
    );
    console.assert(
      typeof taskId === 'string' && taskId.length > 0,
      'taskId must be non-empty string',
    );

    return `${contestId}:${taskId}` as ContestTaskPairKey;
  }

  // 他のメソッド (has, set, delete) も同様に実装
}

export function createContestTaskPairKey(contestId: string, taskId: string): ContestTaskPairKey {
  return `${contestId}:${taskId}`;
}

src/lib/services/tasks.ts への追加

// コンテスト-タスクのマッピングを取得
export async function getContestTaskPairs(): Promise<Map<string, string[]>> {
  const rows = await db.contestTaskPair.findMany({
    select: { contestId: true, taskId: true },
  });

  const map = new Map<string, string[]>();

  for (const r of rows) {
    const arr = m.get(r.taskId) ?? [];
    arr.push(r.contestId);
    map.set(r.taskId, arr);
  }

  return map;
}

// 既存の getTasks() を wrap
export async function getMergedTasks() {
  const tasks = await getTasks();
  const contestTaskPairs = await getContestTaskPairs().catch(() => new Map());

  // contestId:taskId -> Task のマップ（TaskResult 作成で直接参照しやすい）
  const contestTaskPairMap = new Map<string, Task>();
  for (const t of tasks) {
    const contests = contestTaskPairs.get(t.task_id) ?? [t.contest_id];
    for (const c of contests) {
      contestTaskPairMap.set(`${c}:${t.task_id}`, t);
    }
  }

  return { tasks, contestTaskPairs, contestTaskPairMap };
}

src/lib/services/task_results.ts の変更

import { TaskMapAdapter } from '$lib/utils/task_results';
import { getMergedTasks } from '$lib/services/tasks';

// getTaskResults にFeature Flag対応を追加
export async function getTaskResults(userId: string): Promise<TaskResults> {
  const enableContestTaskPair = process.env.ENABLE_CONTEST_TASK_PAIR === 'true';

  if (enableContestTaskPair) {
    console.time('getTaskResults-enhanced');
    console.log(`Processing enhanced mode for user ${userId}`);

    const { tasks, contestTaskPairs } = await getMergedTasks();
    const answers = await answer_crud.getAnswers(userId);

    // enhancedMap を構築
    const enhancedMap: TaskResultByContestTaskPair<TaskAnswer> = new Map();
    for (const [taskId, answer] of answers) {
      const contests = contestTaskPairs.get(taskId) ?? [answer.contest_id ?? ''];
      for (const contestId of contests) {
        if (!contestId) continue;
        enhancedMap.set(`${contestId}:${taskId}`, answer);
      }
    }

    const results = await relateTasksAndAnswers(userId, tasks, answers, enhancedMap);

    console.log(`Generated ${results.length} task results in enhanced mode`);
    console.timeEnd('getTaskResults-enhanced');
    return results;
  } else {
    // 既存の処理
    console.time('getTaskResults-legacy');
    const tasks = await getTasks();
    const answers = await answer_crud.getAnswers(userId);
    const results = await relateTasksAndAnswers(userId, tasks, answers);

    console.log(`Generated ${results.length} task results in legacy mode`);
    console.timeEnd('getTaskResults-legacy');
    return results;
  }
}

// relateTasksAndAnswers のシグネチャ変更（enhancedMap をオプション引数に）
async function relateTasksAndAnswers(
  userId: string,
  tasks: Tasks,
  answers: Map<string, TaskAnswer>,
  enhancedMap?: TaskResultByContestTaskPair<TaskAnswer>,
): Promise<TaskResults> {
  const isLoggedIn = userId !== undefined;
  const adapter = new TaskMapAdapter<TaskAnswer>(answers, enhancedMap);

  const taskResults = tasks.map((task: Task) => {
    const taskResult = createDefaultTaskResult(userId, task);

    if (isLoggedIn && adapter.has(task.task_id, task.contest_id)) {
      const answer = adapter.get(task.task_id, task.contest_id);
      const status = statusById.get(answer?.status_id);
      taskResult.status_name = status.status_name;
      taskResult.submission_status_image_path = status.image_path;
      taskResult.submission_status_label_name = status.label_name;
      taskResult.is_ac = status.is_ac;
      taskResult.updated_at = answer?.updated_at ?? taskResult.updated_at;
    }

    return taskResult;
  });

  return taskResults;
}

6. 移行戦略

Phase 1: 基盤整備

• Prisma スキーマに ContestTaskPair モデル追加
• マイグレーション実行
• TypeScript 型定義追加

Phase 2: 互換性レイヤ導入

• TaskMapAdapter 実装・テスト
• getMergedTasks() 実装
• src/lib/services/task_results.ts への適用

Phase 3: 段階的移行

• 他の影響箇所の特定・修正
• Feature flag による切替制御
• ログ・モニタリング追加

Phase 4: 完全移行

• Legacy マップの削除
• アダプタの簡素化
• パフォーマンス最適化

7. テスト計画

TaskMapAdapter の単体テスト

// filepath: src/lib/utils/task_results.test.ts
import { describe, test, expect } from 'vitest';
import { TaskMapAdapter, createContestTaskPairKey } from './task_results';

describe('TaskMapAdapter', () => {
  test('expect to prioritize enhanced map when contestId is provided', () => {
    const legacy = new Map([['task1', { id: 'legacy' }]]);
    const enhanced = new Map([['contest1:task1', { id: 'enhanced' }]]);
    const adapter = new TaskMapAdapter(legacy, enhanced);

    expect(adapter.get('task1', 'contest1')?.id).toBe('enhanced');
    expect(adapter.get('task1')?.id).toBe('legacy');
  });

  test('expect to fallback to legacy when enhanced not found', () => {
    const legacy = new Map([['task1', { id: 'legacy' }]]);
    const enhanced = new Map();
    const adapter = new TaskMapAdapter(legacy, enhanced);

    expect(adapter.get('task1', 'contest1')?.id).toBe('legacy');
  });

  test('expect to handle write-through correctly', () => {
    const legacy = new Map();
    const enhanced = new Map();
    const adapter = new TaskMapAdapter(legacy, enhanced);

    adapter.set('task1', { id: 'value' }, 'contest1');
    expect(legacy.get('task1')?.id).toBe('value');
    expect(enhanced.get('contest1:task1')?.id).toBe('value');
  });

  test('expect to scan enhanced map when no contestId provided', () => {
    const legacy = new Map();
    const enhanced = new Map([['contest1:task1', { id: 'found' }]]);
    const adapter = new TaskMapAdapter(legacy, enhanced);

    expect(adapter.get('task1')?.id).toBe('found');
    expect(adapter.has('task1')).toBe(true);
  });

  test('expect to validate input parameters', () => {
    const adapter = new TaskMapAdapter(new Map(), new Map());

    // TypeScript strict モードでの型安全性を確保
    expect(() => adapter.get('')).toThrow();
    expect(() => adapter.get('task1', '')).toThrow();
  });
});

describe('createContestTaskPairKey', () => {
  test('expect to create valid key format', () => {
    expect(createContestTaskPairKey('abc001', 'abc001_a')).toBe('abc001:abc001_a');
  });

  test('expect to validate input parameters', () => {
    expect(() => createContestTaskPairKey('', 'task')).toThrow();
    expect(() => createContestTaskPairKey('contest', '')).toThrow();
  });
});

既存テストとの互換性

• 場所: src/test/ の既存単体テスト
• 対応: Feature Flag が false の場合は既存動作を維持
• 確認事項: TaskMapAdapter 導入後も全既存テストがパスすること### 8. パフォーマンス・監視計画

開発環境での監視

// console.log ベースの監視（開発環境のみ）
export async function getTaskResults(userId: string): Promise<TaskResults> {
  if (process.env.NODE_ENV === 'development') {
    console.time('getTaskResults');
    console.log(`Processing ${answers.size} answers for user ${userId}`);
  }

  const results = await getTaskResults(userId);

  if (process.env.NODE_ENV === 'development') {
    console.log(`Generated ${results.length} task results`);
    console.timeEnd('getTaskResults');

    // メモリ使用量確認
    const memory = process.memoryUsage();
    console.log(`Memory usage: ${Math.round(memory.heapUsed / 1024 / 1024)}MB`);
  }

  return results;
}

Staging・本番環境での監視

• ログ確認: Vercel管理者画面
• データ内容: 本番データのサブセット（staging環境）
• メトリクス: 処理時間・データ数・エラー率を最小限ログ出力

APM導入について

• Sentry/DataDog: 導入コストが高いため当面見送り
• 代替手段: console.log + Vercelログでの監視

9. 環境設定・Feature Flag

環境変数設定

# .env または .env.local
ENABLE_CONTEST_TASK_PAIR=false  # 開発段階では false

Feature Flag の適用範囲

• 対象関数: getTaskResults() のみ（段階1）
• 切り替え: 環境変数による制御
• 既存動作: Flag が false の場合は完全に既存処理を維持

データインポート方法

// prisma/seed.ts での ContestTaskPair データ追加例
async function seedContestTaskPairs() {
  const contestTaskPairs = [
    { contestId: 'abc001', taskTableIndex: 'A', taskId: 'abc001_a' },
    { contestId: 'abc001', taskTableIndex: 'B', taskId: 'abc001_b' },
    // ... more data
  ];

  for (const pair of contestTaskPairs) {
    await prisma.contestTaskPair.upsert({
      where: {
        contestId_taskId: {
          contestId: pair.contestId,
          taskId: pair.taskId,
        },
      },
      update: { taskTableIndex: pair.taskTableIndex },
      create: pair,
    });
  }
}

追加討議内容の要約

実装の詳細決定事項

1. ファイル構成: src/lib/utils/task_results.ts に TaskMapAdapter を配置（CRUD分離・テスト容易性・移行後削除容易性）

2. デプロイフロー: 開発 → GitHub Actions → staging環境（Vercel） → 本番環境での段階的検証

3. テストケース:

   • test を使用（it ではなく）
   • expect to 表現に統一（should を避ける）
   • 既存テスト（src/test/）との互換性確保
   • TypeScript strict モードでの型安全性とassert追加

4. パフォーマンス監視:

   • Sentry/DataDog は導入見送り
   • console.log + Vercelログでの監視
   • 開発環境でのみ詳細ログ出力

5. Feature Flag:

   • 環境変数（.env）での制御
   • 適用範囲は getTaskResults() のみ（段階1）

6. データインポート:

   • 第1段階: seed.ts での手動データ投入
   • 第2段階: 管理者画面での自動インポート機能

7. インフラ環境:

   • ソースコード管理: Git/GitHub
   • データベース: Supabase（ロールバック機能あり）
   • staging環境: 本番データのサブセット使用

3. インポート処理の分離

注意: この部分は基本機能実装・動作確認後に改めて討議予定。

• 第1段階: seed.ts や CSV でのデータインポート優先
• 第2段階: 管理者画面を通したインポート機能実装
• AtCoder Problems API からのデータ取得・変換
• 既存 Task データとの整合性確認

リスク要因と対策

リスク	影響度	対策
移行期間中のデータ不整合	高	write-through による二重書き込み + Feature Flag制御
既存機能の破綻	高	互換性レイヤー + 既存テストでの継続検証
パフォーマンス劣化	中	enhanced スキャン処理を移行期間中に限定 + 監視強化
テストカバレッジ不足	中	TaskMapAdapter の単体テスト + TypeScript strict モード
ロールバックの複雑さ	低	Supabaseのロールバック機能 + Feature Flag即座切替

決定事項

1. モデル名: ContestTaskPair
2. 型名: ContestTaskPairKey, TaskResultByContestTaskPair
3. 移行方針: TaskMapAdapter による段階的移行
4. アダプタ配置: src/lib/utils/task_results.ts（影響局所化・テスト容易性・削除容易性）
5. id 属性: 将来性を考慮して追加
6. Feature Flag: 環境変数制御、getTaskResults()のみ適用（段階1）
7. テスト方針: test + expect to + TypeScript strict + assert追加
8. 監視手法: console.log + Vercelログ（APM導入見送り）
9. データ投入: seed.ts優先 → 管理者画面は第2段階

---

作成日: 2025-09-23
ベース: initial_plan.md (2025-09-17)
ステータス: 実装準備段階