pyoco-server 0.4.0__tar.gz

pyoco_server-0.4.0/.codex/skills/architecture-editor/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: architecture-editor
+description: 「architecture.mdを作成/直す」「設計書を書く/修正」「アーキテクチャ設計をまとめる」などの依頼で使用。concept.mdを参照してソフトウェア設計を行い、必要観点を網羅したarchitecture.mdを日本語で作成・更新する。
+---
+
+# Architecture Editor
+
+## 基本方針
+- 出力は日本語で一般的な設計書トーンにする。
+- concept.md を参照して整合性を担保する（用語・UC・機能・データ・レイヤー）。
+- 読みやすさを優先し、一覧系は表形式を使う。
+- 各章の切れ目に空行を1行入れる。
+- CLIが不要な場合は「該当なし」と明記する。
+- クラス/I/F/例外発生条件は具体化する（メソッド名・引数の型/意味・戻り/例外）。
+- I/Fの入出力型・引数型は主要フィールドまで明記する（未記載にしない）。
+- 引数の値・範囲・制約（例: 必須/任意、最小最大、文字種）を明記する。
+- 例外は「発生場所」と「発生原因」がトレースできる情報を含める。
+- UI/ユースケース層で、例外の最終ハンドリング（表示/ID付与）方針を定義する。
+- spec.md がある場合は例外ID/MSG-IDの命名を必ず一致させる（specのERR-ID/MSG-IDを参照）。
+### 汎用観点（必ず満たす）
+- 境界契約の完全性：依存先I/F（Repo/Store等）の最小契約を列挙する。
+- データ契約の具体性：List/Array等の要素型を必ず明記する。
+### 出力の分離ルール
+- 文書本文は単独で出力する（レビュー文は同じ出力に混ぜない）。
+- レビュー提案は文書出力の後、別メッセージで行う。
+
+## 生成フロー（厳守）
+- まず concept.md の有無を確認する。未提示なら concept.md 作成を推奨する。
+- spec.md の有無を確認し、例外ID/MSG-IDの命名を合わせる。
+- concept.md を読み、レイヤー構造・UC・データ・機能の整合を取る。
+- 不足情報は提案案を示し、ユーザーの同意/修正を確認してから生成する。
+
+## 事前確認（提案して確認する）
+- 対象スコープ（全体/機能別）
+- 実行形態（Web/CLI/バッチ/サービス）
+- 永続化の方針（DB/ファイル/外部サービス）
+- 認証/認可の方針
+- 運用前提（デプロイ頻度/更新方針）
+- spec.md があるか（あればERR/MSGのID体系を踏襲する）
+
+## 出力形式
+- `architecture.md` を1つ出力する。
+- 出力は本文のみとし、前後に説明文を付けない。
+
+## architecture.md テンプレート（固定）
+```markdown
+# architecture.md（必ず書く：最新版）
+#1.アーキテクチャ概要（構成要素と責務）
+#2.concept のレイヤー構造との対応表
+（テキスト図示）
+```
+[UI] -> [App] -> [DB/Storage]
+```
+| conceptレイヤー | 対応コンポーネント | 主な責務 |
+|---|---|---|
+|  |  |  |
+#3.インターフェース設計（Interface）
+### UI/APP境界（ユースケース単位）
+#### UC-1: <ユースケース名>
+| 操作/API | 役割 | 入力（型/主要フィールド/値範囲） | 出力（型/主要フィールド） | 例外（発生条件） |
+|---|---|---|---|---|
+|  |  |  |  |  |
+※例外は「発生場所/原因」が分かる形式で記載する。
+
+### 外部I/F（API単位）
+#### API: <外部サービス名>
+| メソッド | 役割 | 入力（型/主要フィールド/値範囲） | 出力（型/主要フィールド） | 例外（発生条件） |
+|---|---|---|---|---|
+|  |  |  |  |  |
+
+### 内部I/F（クラス単位）
+#### Class: <クラス名>
+##### Method: <メソッド名>
+| 引数 | 型 | 意味 | 値範囲/制約 | 必須 |
+|---|---|---|---|---|
+|  |  |  |  |  |
+
+| 戻り値 | 型 | 主要フィールド |
+|---|---|---|
+|  |  |  |
+
+| 例外 | 発生場所 | 発生原因 |
+|---|---|---|
+|  |  |  |
+
+#### 依存先I/F（最小契約）
+| 依存先 | 最小メソッド | 目的 |
+|---|---|---|
+| Repo/Store | save/find/update | 永続化 |
+
+### 型定義（入出力/DTOの主要フィールド）
+| 型 | 主要フィールド（値範囲/制約） | 用途 |
+|---|---|---|
+|  |  |  |
+※List/Arrayは要素型を必ず明記する（例: items: array<ExpenseSummary>）
+#4.主要フロー設計（成功/失敗）
+| フロー | 成功条件 | 失敗条件 | 例外時の動作 |
+|---|---|---|---|
+|  |  |  |  |
+#5.データ設計（永続化・整合性・マイグレーション）
+| データ | 永続化 | 整合性 | マイグレーション |
+|---|---|---|---|
+|  |  |  |  |
+#6.設定：場所／キー／既定値
+| 項目 | 場所 | キー | 既定値 |
+|---|---|---|---|
+|  |  |  |  |
+#7.依存と拡張点（Extensibility）
+| 依存 | 目的 | 拡張点 |
+|---|---|---|
+|  |  |  |
+#7.5.依存関係（DI）
+（テキスト図示）
+```
+<Class> -> <Interface>
+```
+| クラス | コンストラクタDI（依存先） | 目的 |
+|---|---|---|
+|  |  |  |
+#8.エラーハンドリング設計（冪等性/リトライ/タイムアウト/部分失敗）
+| 事象 | 発生場所 | 発生原因 | 方針 | 備考 |
+|---|---|---|---|---|
+|  |  |  |  |  |
+#9.セキュリティ設計（秘密情報・最小権限・ログ方針）
+| 観点 | 方針 |
+|---|---|
+|  |  |
+#10.観測性（ログ/診断：doctor/status/debug）
+| 種別 | 内容 | 出力先 |
+|---|---|---|
+|  |  |  |
+## 例外ハンドリング方針（UI/ユースケース層）
+| UC | 例外 | 表示/通知 | エラーID/コード方針 | 関連spec ERR-ID |
+|---|---|---|---|---|
+|  |  |  |  |  |
+#11.テスト設計（単体/統合/E2E、モック方針）
+| 種別 | 対象 | 方針 |
+|---|---|---|
+|  |  |  |
+#12.配布・実行形態（インストール/更新/互換性/破壊的変更）
+#13.CLI：コマンド体系／引数／出力／exit code
+```
+
+## 整合性チェック
+- concept.md のレイヤー/機能/UC/データと対応が取れているか確認する。
+- 主要フローが concept.md のUCをカバーしているか確認する。
+- エラーハンドリングが主要フローの失敗条件と矛盾しないか確認する。
+- セキュリティ/観測性/テストが実行形態と矛盾しないか確認する。
+- テキスト図示がレイヤー構造と矛盾しないか確認する。
+- UI/APP境界I/FがUC単位で整理されているか確認する。
+- 内部I/Fがクラス単位で整理され、メソッド単位の表になっているか確認する。
+- 例外の発生条件がI/F・フロー・エラーハンドリングで整合しているか確認する。
+- 依存関係（DI）がレイヤー構造と矛盾しないか確認する。
+- 依存先I/Fの最小契約が列挙されているか確認する。
+- List/Arrayの要素型が明記されているか確認する。
+- 例外の発生場所/原因が追跡可能か確認する。
+- UI/UC層の最終ハンドリング（表示/ID）が定義されているか確認する。
+- spec.md がある場合、例外ID/MSG-IDが矛盾していないか確認する。
+
+## 出力後の提案（レビュー促進）
+- 文書出力の次メッセージで、必ずレビュー提案を行う（下記テンプレートを使用）。
+
+### レビュー提案テンプレート（固定文）
+「SWEエージェント観点でarchitectureを評価します。評価としては100点満点でXX点くらいで、こういった点は改善した方がいいかもしれません、というレビューをしますか？」
+
+### レビュー出力フォーマット（固定）
+- 評価: XX点 / 合格（または要改善）
+- 良い点
+  - 箇条書き
+- 改善した方が良い点
+  - 箇条書き
+- 次のアクション
+  - 修正したい点があれば教えてください（修正します）
+
+### レビュー時のルール
+- 100点満点で評価し、80点以上なら「合格」を明示する（例: 「評価: 85点 / 合格」）。
+- 改善点は具体的に列挙し、修正希望があれば反映する。
+### 設計評価の観点（必ず触れる）
+- ゴッドクラス/ゴッドI/Fになっていないか（責務肥大の有無）
+- 単一責務（SRP）が守られているか
+- 依存部品がコンストラクタDI可能か
+- テスト可能性（モック差し替え・境界分離）

pyoco_server-0.4.0/.codex/skills/concept-editor/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: concept-editor
+description: 「concept.mdを作成」「conceptを作る/直す/修正」「concept文書を評価/レビュー」など、concept.mdの作成・更新・評価を行う。プロダクト概念・ユースケース・機能ブロック・主要データの整合性を担保しながら編集する固定11セクション形式。仕様書の概要やサービス企画の文書化依頼で使用。
+---
+
+# Concept Editor
+
+## 基本方針
+- 出力は日本語で一般的な仕様書トーンにする。
+- 出力は concept.md 本文のみとし、前後の説明文を付けない。
+- フォーマットは下記テンプレートに完全一致させる。
+- 既存の concept.md がある場合は内容を活かしつつ、テンプレート順に整形する。
+- 出力品質の基準が必要なときは `references/sample-concept.md` を読み、構成・粒度を合わせる。
+- 読みやすさを優先し、一覧系は表形式で作成する（#5, #6, #8, #9）。
+- 各章の切れ目に空行を1行入れる（詰め込みを避ける）。
+### 出力の分離ルール（矛盾回避）
+- concept.md 本文は単独で出力する（レビュー文は同じ出力に混ぜない）。
+- レビュー提案は concept.md 出力の後、別メッセージで行う。
+
+## 情報収集と仮説
+- 不足情報は質問で補う。質問は重要度が高い順に最大5件までに抑える。
+- 不足があっても推測できる場合は妥当な案を提示し、「この前提で良いか」を確認する。
+- ユーザーが未認識の観点がありそうなら、仮説を提案して引き出す。
+### 生成フロー（厳守）
+- まず「提案案（4観点）」を提示し、ユーザーの同意/修正を確認する。
+- 同意後に concept.md を生成する。
+
+### 最小質問例
+- 何を作るか（製品/サービスの一言要約）
+- 誰のどんな困りごとを解決するか
+- 主要なユースケース（2〜5件）
+- 使われる場面や前提環境（端末/OS/ネットワーク/社内外など）
+- 技術スタックの希望や制約
+
+### 生成前に提案して確認すべき観点（範囲の曖昧さを潰す）
+- 役割と権限範囲（利用者/管理者/閲覧者などの操作範囲）
+- データの保存方針（削除/退職者/履歴保持/監査の必要性）
+- データの公開範囲（社内のみ/部署内/個人のみ）
+- 例外時の扱い（操作不可の条件、競合・二重操作の扱い）
+#### 必須運用
+- 上記4観点は必ず「こちらの提案案」を先に示し、ユーザーの同意/修正を確認してから生成する。
+
+### 仮説の立て方（情報不足時）
+- プラットフォーム未指定なら「Webアプリ（PC/スマホ両対応）」を仮定する。
+- ターゲット未指定なら「業務担当者/管理者」を仮定する。
+- 仮説は「前提（Assumptions）」に明記し、了承が得られるか確認する。
+
+## 出力テンプレート（厳守）
+```markdown
+# concept.md（必ず書く：最新版）
+#1.概要（Overview）（先頭固定）
+- 作るもの（What）：
+- 解決すること（Why）：
+- できること（主要機能の要約）：
+- 使いどころ（When/Where）：
+- 成果物（Outputs）：
+- 前提（Assumptions）：
+
+#2.ユーザーの困りごと（Pain）
+
+#3.ターゲットと前提環境（詳細）
+
+#4.採用する技術スタック（採用理由つき）
+
+#5.機能一覧（Features）
+| ID | 機能 | 解決するPain | 対応UC |
+|---|---|---|---|
+| F-1 |  |  | UC-1 |
+
+#6.ユースケース（Use Cases）
+| ID | 主体 | 目的 | 前提 | 主要手順（最小操作） | 成功条件 | 例外/制約 |
+|---|---|---|---|---|---|---|
+| UC-1 |  |  |  |  |  |  |
+
+#7.Goals（Goalのみ／ユースケース紐づけ必須）
+- G-1: （対応：UC-1）
+
+#8.基本レイヤー構造（Layering）
+| レイヤー | 役割 | 主な処理/データ流れ |
+|---|---|---|
+| プレゼンテーション層 |  |  |
+
+#9.主要データクラス（Key Data Classes / Entities）
+| データクラス | 主要属性（不要属性なし） | 用途（対応UC/Feature） |
+|---|---|---|
+|  |  |  |
+
+#10.機能部品の実装順序（Implementation Order）
+
+#11.用語集（Glossary）
+```
+
+## セクション別の作成ルール
+- #1 は6項目すべて埋める。
+- #4 は採用理由を必ず併記する（1行で良い）。
+- #5 は表形式で F-1, F-2… と採番する。
+- #6 は表形式で UC-1, UC-2… の形式で採番する。主要手順は最小操作で具体的に書く。
+- #7 は G-1, G-2… の形式で採番し、各Goalに「対応：UC-?」を必ず付ける。
+- #7 は Goal のみを書く（達成指標や実装詳細は書かない）。
+- #10 は順序が分かるように番号付きで並べる。
+- 追加セクションは作らない。
+
+## 最小性の判断ガイド（内容依存だが基準は固定）
+### 過剰機能を避ける
+- 機能は「Painを解決するために必要な最小集合」に限定する。
+- 各機能に「解決するPain / 対応UC」を必ず割り当てる。割り当てできない機能は削除候補。
+- 反証テスト: その機能を削ってもPain/UCが成立するなら過剰機能とみなす。
+
+### 最小操作にする
+- ユーザーの明示操作（入力/クリック/画面遷移）を最小化する。
+- 同一情報の再入力は不可。既存データ/自動補完/推定で代替できるなら採用する。
+- UCごとに「必須入力」と「自動化できる入力」を分け、後者は極力排除する。
+- UCで必要な操作が多い場合、フローを短縮する代替案を必ず検討する。
+
+### 最小データにする
+- データクラスは「UCを成立させるために必須の永続データ」に限定する。
+- 各データクラスは「不要属性がない」ことを確認する（使われない/重複/推測可能な属性は削除候補）。
+- 派生データは原則保存せず算出に寄せる（必要な場合のみ保存理由を明記）。
+- 1つの概念は1つの正のソース（Single Source of Truth）に集約する。
+- レイヤー/ブロックはUCに必要な最小データ流れのみを通す（冗長な中間層を作らない）。
+
+## 対応表チェック（整合性を担保する）
+- Pain → UC → Features → Layering → Data Classes の順で「対応できること」を確認する。
+- 逆方向にも検証する（Data Classes → Layering → Features → UC → Pain）。対応先がない要素は削除候補。
+- 1つのPainは最低1つのUCで解決されること。
+- 1つのUCは最低1つのFeatureで支えられること。
+- FeatureはLayering上のブロック/層に必ず割り当てること。
+- Data Classは必ずFeatureまたはUCに登場すること（未使用データは削除候補）。
+
+## 技術スタックの分岐指針（簡潔に）
+- まず「希望する言語/フレームワーク」を確認する。
+- 希望がない場合は、用途に合うメジャー技術を2〜3案提示して選んでもらう。
+- 速度優先・少人数運用: マネージドサービス優先（例: フロントSPA + BaaS）。
+- 高い拡張性・複雑要件: 標準的3層（Web/API/DB）で保守性を優先。
+- リアルタイム要件: WebSocket/Push対応を明記する。
+- オフライン/現場利用: ローカルキャッシュ/同期方式を明記する。
+- 既存環境制約（言語/クラウド/DB）がある場合は最優先で採用する。
+### メジャー技術の提示例（希望がない場合）
+- フロント: React + TypeScript / Vue + TypeScript
+- バックエンド: Node.js(NestJS) / Python(FastAPI) / Java(Spring Boot)
+- DB: PostgreSQL / MySQL
+- インフラ: Docker + 主要クラウド（AWS/GCP/Azure）
+
+## 品質チェック
+- 11セクションすべて存在するか確認する。
+- #7 の対応UCが #6 に存在するか確認する。
+- 前提・技術・ユースケースが矛盾していないか確認する。
+- #2 の困りごとが #5 の最小機能で解決できているか確認する（過剰機能を避ける）。
+- #6 のユースケースが最小操作で完結するか確認する（頻繁な入力要求や多操作を避ける）。
+- #8 のレイヤー/ブロックが #6 のユースケースを実現する最小のデータ流れとして構造化されているか確認する。
+- 対応表チェックの両方向（Pain→…→Data / Data→…→Pain）が成立するか確認する。
+### 出力後の提案（レビュー促進）
+- 生成後に必ずレビュー提案を添える（下記テンプレートを使用）。
+- レビュー提案は concept.md 出力の「次のメッセージ」で必ず送る。
+
+#### レビュー提案テンプレート（固定文）
+「SWEエージェント観点でconceptを評価します。評価としては100点満点でXX点くらいで、こういった点は改善した方がいいかもしれません、というレビューをしますか？」
+
+#### レビュー出力フォーマット（固定）
+- 評価: XX点 / 合格（または要改善）
+- 良い点
+  - 箇条書き
+- 改善した方が良い点
+  - 箇条書き
+- 次のアクション
+  - 修正したい点があれば教えてください（修正します）
+
+#### レビュー時のルール
+- 100点満点で評価し、80点以上なら「合格」を明示する（例：「評価: 85点 / 合格」）。
+- 改善点は具体的に列挙し、修正希望があれば反映する。

pyoco_server-0.4.0/.codex/skills/concept-editor/references/sample-concept.md

@@ -0,0 +1,69 @@
+# concept.md（必ず書く：最新版）
+#1.概要（Overview）（先頭固定）
+- 作るもの（What）：社内備品の貸出・返却を簡単に管理できるWebアプリ
+- 解決すること（Why）：備品の所在不明や二重貸出、返却漏れをなくす
+- できること（主要機能の要約）：空き備品の確認、貸出登録、返却登録、備品登録
+- 使いどころ（When/Where）：社内からPC/スマホで備品を借りたいとき
+- 成果物（Outputs）：貸出中一覧、空き備品一覧、備品台帳
+- 前提（Assumptions）：社内利用、SSOでユーザー識別、ネットワーク常時接続
+
+#2.ユーザーの困りごと（Pain）
+- 備品の空き状況が分からず、探す時間がかかる
+- いつ誰が借りたか把握できず、返却漏れが発生する
+- 台帳が更新されず、現物と記録が一致しない
+
+#3.ターゲットと前提環境（詳細）
+- ターゲット：社内の一般社員（利用者）、総務/IT（管理者）
+- 環境：社内ネットワーク、PC/スマホ対応、ブラウザ利用
+
+#4.採用する技術スタック（採用理由つき）
+- フロント：React + TypeScript（保守性と開発生産性が高い）
+- バックエンド：Node.js(NestJS)（API設計が整理しやすい）
+- DB：PostgreSQL（貸出履歴などのリレーション管理に強い）
+- インフラ：Docker + AWS（社内運用と拡張性のバランス）
+
+#5.機能一覧（Features）
+| ID | 機能 | 解決するPain | 対応UC |
+|---|---|---|---|
+| F-1 | 備品一覧/空き状況表示 | 空き不明 | UC-1 |
+| F-2 | 貸出登録 | 二重貸出 | UC-1 |
+| F-3 | 返却登録 | 返却漏れ | UC-2 |
+| F-4 | 備品登録/更新 | 台帳不一致 | UC-3 |
+
+#6.ユースケース（Use Cases）
+| ID | 主体 | 目的 | 前提 | 主要手順（最小操作） | 成功条件 | 例外/制約 |
+|---|---|---|---|---|---|---|
+| UC-1 | 利用者 | 空き備品を貸出する | SSOでログイン済み | 1) 一覧で空きを確認 2) 備品を選択 3) 貸出登録 | 貸出中一覧に反映される | 貸出中の備品は選択不可 |
+| UC-2 | 利用者 | 備品を返却する | 貸出中の備品がある | 1) 自分の貸出一覧を開く 2) 返却登録 | 返却済みとして一覧から外れる | 返却済みの二重返却は不可 |
+| UC-3 | 管理者 | 備品情報を最新化する | 管理者権限 | 1) 備品一覧を開く 2) 登録/更新 3) 保存 | 備品台帳に反映される | 必須項目が欠けると保存不可 |
+
+#7.Goals（Goalのみ／ユースケース紐づけ必須）
+- G-1: 備品の空き状況が即時に分かる（対応：UC-1）
+- G-2: 返却漏れが減る（対応：UC-2）
+- G-3: 備品台帳が最新化される（対応：UC-3）
+
+#8.基本レイヤー構造（Layering）
+| レイヤー | 役割 | 主な処理/データ流れ |
+|---|---|---|
+| プレゼンテーション層 | 入力/表示 | 備品一覧/貸出/返却/管理画面 |
+| アプリ層 | 業務ロジック | 空き判定、貸出登録、返却登録、備品登録 |
+| データ層 | 永続化 | 備品・貸出・ユーザー情報の読み書き |
+
+#9.主要データクラス（Key Data Classes / Entities）
+| データクラス | 主要属性（不要属性なし） | 用途（対応UC/Feature） |
+|---|---|---|
+| Equipment | id, name, category, is_active | UC-1/UC-3, F-1/F-4 |
+| Loan | id, equipment_id, borrower_id, loaned_at, returned_at | UC-1/UC-2, F-2/F-3 |
+| User | id, name, role | UC-1/UC-2/UC-3 |
+
+#10.機能部品の実装順序（Implementation Order）
+1. Equipment/Loanのデータモデルと基本API
+2. 備品一覧と空き状況表示
+3. 貸出登録フロー
+4. 返却登録フロー
+5. 備品登録/更新（管理者）
+
+#11.用語集（Glossary）
+- 備品：社内で共有する物品（PC、プロジェクター等）
+- 貸出：備品を一時的に利用者に紐づけること
+- 返却：貸出状態を終了し備品を戻すこと

pyoco_server-0.4.0/.codex/skills/plan-editor/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: plan-editor
+description: 「plan.mdを作成/直す」「実装計画を書く/更新」「開発計画（実装/テスト/文書化）を整理する」「planに追加して」「planをアーカイブにして」などの依頼で使用。機能実装・テスト・文書化の計画を日本語で plan.md に作成・更新する。
+---
+
+# Plan Editor
+
+## 基本方針
+- 出力は日本語で一般的な計画書トーンにする。
+- 出力は plan.md 本文のみとし、前後の説明文を付けない。
+- current / future / archive の3区分で管理する。
+- 各章の切れ目に空行を1行入れる。
+
+## 生成フロー（厳守）
+- 全体と機能が分かれているか確認する。
+  - 分かれている場合: 全体は future に置き、着手中の機能を current に置く。
+  - 全体のみの場合: 着手する部分を current に置く。
+- 不足情報は提案案を示し、ユーザーの同意/修正を確認してから生成する。
+
+## current のルール
+- チェックリスト形式で高い粒度で記載する（`- [ ]` / `- [x]`）。
+- 「機能を実装 → 直後にテスト」を1セットにする。
+- concept/spec/architecture の現状確認を最初に入れる。
+- 文書化が必要なら最初に実施する（仕様書/設計書/運用文書の更新）。
+- 実施中にうまく行かない場合は、デバッグメッセージ追加を含むデバッグ項目に組み替える。
+- 機能部品から単体テストし、最終的にE2Eテストを行う。
+- 最後に文書との整合性をテストする。
+- 各項目は対象を具体化する（対象ファイル/機能/範囲を明記）。
+
+## future のルール
+- 大雑把な将来計画を記載する（concept未実現機能など）。
+- チェックのないリスト形式で記載する。
+
+## archive のルール
+- 実施済みアイテムの記録。
+- 「planをアーカイブにして」と言われたら current の完了項目を移動する。
+
+## plan.md テンプレート（固定）
+```markdown
+# plan.md（必ず書く：最新版）
+
+# current
+- [ ] 例: concept/spec/architecture の現状を確認する
+- [ ] 例: 仕様書/設計書に必要な変更点を反映する
+- [ ] 例: xxxxにxxxxを実装する
+- [ ] 例: xxxxのxxxxをテストする
+- [ ] 例: xxxxにyyyyを実装する
+- [ ] 例: xxxxのyyyyをテストする
+- [ ] 例: xxxxの機能をE2Eテストする
+- [ ] 例: 文書との整合性を確認する
+
+# future
+- 例: xxxx 機能
+- 例: XXXをmmmしたい
+
+# archive
+- [x] 例: ccc
+- [x] 例: dddd
+```
+
+## 整合性チェック
+- current はチェックリスト形式になっているか確認する。
+- 「実装→直後にテスト」の並びになっているか確認する。
+- 単体→E2E→文書整合の順序が含まれているか確認する。
+- future はチェックなしのリストになっているか確認する。
+- archive は完了項目（`[x]`）のみか確認する。

pyoco_server-0.4.0/.codex/skills/spec-editor/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: spec-editor
+description: 「仕様書を作る/直す」「spec.mdを作成/修正」「仕様書(spec.md相当)を作って/直して」などの依頼で使用。concept.mdを参照して規模を判断し、全体または機能単位の仕様書を日本語で整合性を保って作成・更新する。
+---
+
+# Spec Editor
+
+## 基本方針
+- 出力は日本語で一般的な仕様書トーンにする。
+- concept.md を参照して整合性を担保する（用語・UC・機能・データ）。
+- 読みやすさを優先し、一覧系は表形式を使う。
+- 各章の切れ目に空行を1行入れる。
+- I/F詳細・API使用の詳細は書かない（要件レベルに留める）。
+- 要件は「正常系（XXする/できる）」のみを書く。
+- エラーは各要件の枝番仕様として整理し、ERR/MSGと必ず紐づける。
+- 通信断/タイムアウト/バリデーション/権限/競合/重複/対象なし/ファイルアクセス失敗/DB記録失敗/長時間処理の多重起動等の典型エラーは可能な限り盛り込む。
+### 出力の分離ルール
+- 仕様書本文は単独で出力する（レビュー文は同じ出力に混ぜない）。
+- レビュー提案は仕様書出力の後、別メッセージで行う。
+
+## 生成フロー（厳守）
+- まず concept.md の有無を確認する。未提示なら要約を依頼する。
+- concept.md を読み、規模判定表で「全体仕様のみ」か「機能別仕様」に分ける。
+- 不足情報は提案案を示し、ユーザーの同意/修正を確認してから生成する。
+
+## 規模判定（concept.mdから判断）
+| 条件 | 出力 |
+|---|---|
+| UC ≤ 5 かつ Feature ≤ 8 かつ 主要ロール ≤ 3 | 全体仕様のみ（spec.md） |
+| 上記のいずれかを超える | 全体仕様 + 機能別仕様 |
+
+### 例外
+- ユーザーが明示的に指定した場合はそちらを優先する。
+
+## 事前確認（提案して確認する）
+- 対象スコープ（全体/機能別の分割方針）
+- 対象ユーザー/権限範囲（ロールごとの操作）
+- データの保存方針（履歴保持・削除・監査）
+- 公開範囲（社内/部署/個人）
+- 例外/制約（競合・重複・不可条件）
+- REQ-IDの命名ルール（プロジェクト名/機能短縮名のどちらを使うか）
+
+## 出力形式
+- 全体仕様のみ: `spec.md` を1つ出力する。
+- 機能別仕様: `spec.md`（全体） + `spec/feature-<id>.md` を出力する。
+- 機能別仕様は `xxxx_spec.md`（機能名に応じたファイル名）でもよい。
+- 複数ファイルの場合は、各ファイルを個別のコードブロックで示し、先頭にファイル名行を付ける。
+
+## spec.md テンプレート（全体仕様）
+```markdown
+# <プロジェクト名>
+
+要件とは（レビュー者視点）＋ Given/When/Done ＋ MSG/ERR のID管理  
+※I/F詳細・API使用は書かない
+
+# 要件一覧（Requirements）
+| ID | 要件（固定書式・正常系のみ） | 関連UC-ID |
+|---|---|---|
+| REQ-0001 | XXXをしたら、YYYYする。 | UC-1 |
+
+### [<プロジェクト名>-0001] XXXをしたら、YYYYする。
+Given：前提状態  
+When：トリガ（ユーザー操作や内部イベント）  
+Done：完了条件（観測可能な結果）
+
+#### エラー分岐（REQ-0001の枝番）
+| ERR-ID | 発生条件 | ユーザーアクション | 関連MSG-ID |
+|---|---|---|---|
+| ERR-<プレフィックス>-0001 |  |  | MSG-<プレフィックス>-0001 |
+
+（必要なら）短い例：
+- 例：XXXをしたら、YYYYする。
+
+## メッセージID管理（MSG-xxxx）
+| ID | 文面テンプレ | 出力先 | 発生条件 | 関連REQ/ERR |
+|---|---|---|---|---|
+| MSG-<プレフィックス>-0001 |  |  |  | REQ-0001 |
+
+## エラーID管理（ERR-xxxx）
+| ID | 原因 | 検出条件 | ユーザーアクション | 再試行可否 | 関連MSG-ID | 関連REQ |
+|---|---|---|---|---|---|---|
+| ERR-<プレフィックス>-0001 |  |  |  | 可/不可 | MSG-<プレフィックス>-0001 | REQ-0001 |
+```
+
+## 機能別仕様テンプレート
+```markdown
+# <機能名>
+
+要件とは（レビュー者視点）＋ Given/When/Done ＋ MSG/ERR のID管理  
+※I/F詳細・API使用は書かない
+
+# 要件一覧（Requirements）
+| ID | 要件（固定書式・正常系のみ） | 関連UC-ID |
+|---|---|---|
+| REQ-0001 | XXXをしたら、YYYYする。 | UC-1 |
+
+### [<機能名>-0001] XXXをしたら、YYYYする。
+Given：前提状態  
+When：トリガ（ユーザー操作や内部イベント）  
+Done：完了条件（観測可能な結果）
+
+#### エラー分岐（REQ-0001の枝番）
+| ERR-ID | 発生条件 | ユーザーアクション | 関連MSG-ID |
+|---|---|---|---|
+| ERR-<プレフィックス>-0001 |  |  | MSG-<プレフィックス>-0001 |
+
+（必要なら）短い例：
+- 例：XXXをしたら、YYYYする。
+
+## メッセージID管理（MSG-xxxx）
+| ID | 文面テンプレ | 出力先 | 発生条件 | 関連REQ/ERR |
+|---|---|---|---|---|
+| MSG-<プレフィックス>-0001 |  |  |  | REQ-0001 |
+
+## エラーID管理（ERR-xxxx）
+| ID | 原因 | 検出条件 | ユーザーアクション | 再試行可否 | 関連MSG-ID | 関連REQ |
+|---|---|---|---|---|---|---|
+| ERR-<プレフィックス>-0001 |  |  |  | 可/不可 | MSG-<プレフィックス>-0001 | REQ-0001 |
+```
+
+## 整合性チェック
+- concept.md の UC/Feature と要件の関連UC-IDが一致するか確認する。
+- 要件一覧の REQ-xxxx と詳細見出し（<プロジェクト名/機能名>-xxxx）の番号が一致するか確認する。
+- 各要件に Given/When/Done が揃っているか確認する。
+- 要件一覧は正常系のみで書かれているか確認する。
+- 各要件のエラー分岐が ERR/MSG と紐づいているか確認する。
+- MSG/ERR が REQ と紐づいているか確認する。
+- I/F詳細・API使用の詳細が書かれていないか確認する。
+- concept.md のユースケースが仕様書群（spec.md + 機能別仕様）で網羅されているか確認する。
+  - 単一の spec.md だけで網羅できない場合は、機能別仕様でのカバーを明記する。
+
+## 出力後の提案（レビュー促進）
+- 仕様書出力の次メッセージで、必ずレビュー提案を行う（下記テンプレートを使用）。
+
+### レビュー提案テンプレート（固定文）
+「SWEエージェント観点でspecを評価します。評価としては100点満点でXX点くらいで、こういった点は改善した方がいいかもしれません、というレビューをしますか？」
+
+### レビュー出力フォーマット（固定）
+- 評価: XX点 / 合格（または要改善）
+- 良い点
+  - 箇条書き
+- 改善した方が良い点
+  - 箇条書き
+- 次のアクション
+  - 修正したい点があれば教えてください（修正します）
+
+### レビュー時のルール
+- 100点満点で評価し、80点以上なら「合格」を明示する（例: 「評価: 85点 / 合格」）。
+- 改善点は具体的に列挙し、修正希望があれば反映する。
+
+## REQ-ID ルール（必須）
+- REQ-xxxx は4桁のゼロ埋め連番とする（例: REQ-0001）。
+- 詳細見出しは `[<プレフィックス>-xxxx]` を使う。
+  - プレフィックスは「プロジェクト名」または「機能短縮名」のどちらでもよい。
+  - どちらを使うかは事前確認で決め、文書内で統一する。
+- 採番単位はプロジェクト単位とし、複数spec間で重複しない。
+
+## MSG/ERR-ID ルール（必須）
+- MSG/ERR は `MSG-<プレフィックス>-xxxx` / `ERR-<プレフィックス>-xxxx` とする。
+- <プレフィックス> は REQ と同一の命名方針（プロジェクト名 or 機能短縮名）で統一する。
+- 採番単位はプロジェクト単位とし、複数spec間で重複しない。

pyoco_server-0.4.0/.gitignore

@@ -0,0 +1,10 @@
+# Python-generated files
+__pycache__/
+*.py[oc]
+build/
+dist/
+wheels/
+*.egg-info
+
+# Virtual environments
+.venv

pyoco_server-0.4.0/.python-version

@@ -0,0 +1 @@
+3.10