最初のセッション

新しいエンドポイント /users/stats を作成し、ユーザー数と平均登録年齢を含む JSON オブジェクトを返すようにしてください。 

既存の PostgreSQL の users テーブルを使用してください。 

レスポンス構造については、statsController.js 内の /orders/stats エンドポイントを参照してください。 

新しいエンドポイントが StatsController.test.js スイートでカバーされていることを確認してください。

`UserProfileComponent` に、ユーザーのロール（admin, editor, viewer）を一覧表示するドロップダウンを追加してください。 

スタイリングには `DropdownBase` を使用してください。 

ロールが選択されたら、既存の API を呼び出してユーザーのロールを設定してください。 

選択によって DB 上のユーザーのロールが更新されていることを確認してください。適切なテスト方法については Knowledge を参照してください。

既存コードの移行またはリファクタリング
logger.js を JavaScript から TypeScript に移行してください。

すでに tsconfig.json と、検証用の LoggerTest.test.js テストスイートがあります。

エラーなくコンパイルできることを確認し、既存の設定は変更しないでください。

移行後は、次を実行して確認します:
1) `tsc` を実行して型エラーがないことを確認する
2) `npm test LoggerTest.test.js` でテストスイートを実行し、すべてのテストが通ることを確認する
3) コードベース全体で既存の logger メソッド呼び出しが、型エラーなしで動作していることを確認する

現在、pg から Sequelize への移行を行っています（https://sequelize.org/api/v6/identifiers を参照してください）。 

UserModel のクエリを、Sequelize のメソッドを使うように更新してください。 

このコードベースでの実装方法については、OrderModel を参照してください。

実装後は、以下を実行して検証してください:
1) `npm run test:integration UserModel.test.js` を実行し、すべてのインテグレーションテストが通ることを確認する
2) 1000 ユーザーのテストデータセットに対する実行時間を確認し、クエリのパフォーマンスが低下していないことを確認する
3) `npm run test:e2e user-flows.test.js` を実行し、すべての CRUD 操作でデータ完全性が維持されていることを検証する

## 概要
このタスクでは、あるリポジトリに対して素早く pull request を作成します。
これは「クイック」PR なので、コードを実行したりテストを行う必要はありません。PR を作成するだけで、テストはユーザー側が対応します。あなたの責任はコードの読み書きのみです。

## ユーザーから必要なもの
- pull request を作成する対象のリポジトリ

## 手順
### 作業環境の準備
1. 手元のマシンで対象リポジトリに移動します（分からない場合はユーザーに確認してください）。
    - main ブランチをチェックアウトし、main ブランチの名前を控えておきます。
    - pull request を作成するため、新しいブランチをチェックアウトします。ブランチ名は `devin/<your-branch-name>/X` という形式にし、X は任意の数字にします。例: `devin/fix-popup/3234`。`git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` を実行し、`{branch-name}` を作成したいブランチ名に置き換えてください。
2. リクエスト内容・コードベースを確認し、変更内容を計画する
    - 最も関連性の高いファイルやコードセクションを確認し、関連するスニペットを特定します。
    - 変更の方針をユーザーに共有します。
### PR 作成作業
3. コードを変更する
    - ユーザーから明示的に依頼されていないものは変更しないでください。
4. PR を作成する
    - 変更をコミット・プッシュし、その旨をユーザーに伝えます。
    - PR を作成するための正確なコマンドは「アドバイス」セクションを参照してください。
    - pull request を作成し、見た目や内容に問題がないか自己レビューします。
    - すべての GitHub Actions が正常に通過していることを確認し、失敗する場合は通過するまで必要な修正を行ってください。
    - PR のリンクをユーザーに送り、変更内容を要約します。
5. レビューからのフィードバックに対応する。変更を行うたびに、毎回 PR のリンクを再度送付する
    - 更新が必要な場合は、同じブランチにコミットを追加でプッシュしてください。新しいブランチは作成しないでください。


## タスク仕様
- PR のリンクをユーザーへのメッセージに含めること
- 作成後に PR をレビューしていること
- PR に不要な変更が含まれていないこと
- PR がユーザーから明示的に依頼されていない内容を一切変更していないこと
- PR の説明には、変更内容のサマリをチェックリスト形式で含めること
- PR の説明には、コードがテストされていないことを明記し、項目として - [ ] Test the changes を含めること
- PR の説明には、次のフッターを含めること: "This PR was written by [Devin](https://devin.ai/) :angel:"
- PR の説明には、ユーザーが提供したメタデータ（例: 適切な構文で記述された Linear チケットのタグ）を含めること
- PR の説明が不正なフォーマットになっていないこと（改行が崩れる場合は --body ではなく --body-file を使用してください！）

## 禁止事項
- ブラウザ経由で github.com にアクセスしようとしないでください。認証されていません。
- ブランチに対して絶対に force push しないでください！作業内容を失わないよう、rebase ではなく merge を優先してください。
- main ブランチへ直接 push しないでください。

## アドバイスとポイント
- main ブランチ名（`main` または `master` など）を `git branch` を使って必ず再確認してください。
- GitHub Actions で CI/CD を行っているリポジトリでは、`gh` CLI を使ってビルドログを確認できます。ビルド修正や lint 修正を求められた場合は、まず直近のビルドログを確認してください。
- ファイルを追加・コミットする前に `git status` を確認してください。
- コミット前に、`git diff` を使用して自身が行った変更を確認してください。
- 既存のリポジトリを更新する場合は、`gh` CLI を使って pull request を作成してください。
- 変更を更新するたびに PR リンクをユーザーへ送り、再レビューを依頼して、ユーザー側の利便性を高めてください。
- ユーザーから知らせてもらったすべてのリポジトリにアクセスできるよう、すでに認可されているはずです。もしアクセスできない場合は、ユーザーにアクセス権を依頼してください。