コンテンツにスキップ

品質保証

このページは、cpersona のリリースがどのようにゲートされているかを説明します。読み手として想定しているのは、大切なコーパスをこのサーバーに預けてよいかを判断しようとしている人と、自分の変更がどの検査を通ることになるのかを知りたいコントリビューターです。

プルリクエストを出す前に検査を実行する方法を探しているなら、短い版が CONTRIBUTING § The gates にあります。

監査でゲートされたリリース

リリースを切る前に、コードベースは多エージェントによる監査ラウンドを何周か通ります。観点ごとに独立した finder を立て、各 finding をさらに複数のレンズから敵対的に検証することで、「もっともらしいが誤っている」報告が修正まで生き残らないようにしています。v2.4.39 はそうしたラウンドを 3 周してから出荷しました。43 件の修正があり、そのすべてを着地したツリーに対して再検証しています。

監査が生むのは finding であって修正ではありません。生き残った finding は、何かを編集する前にバグ台帳の採番済みエントリになります。こうすることで、コミットと台帳が bug-NNN の指す対象について食い違わなくなります。

バグ台帳

監査済みの欠陥はすべて qa/issue-registry.json に、機械検査可能なコードパターンとともに記録されます。その欠陥が何であったか、何によって再現するか、何が閉じたかが残ります。

scripts/verify-issues.sh は台帳をツリーと突き合わせ、修正マーカーが消えたり、除去したはずの欠陥が戻ってきたりすると、声を上げて失敗します。これは read-only のインフラです。台帳を検証するためのものであり、検査を通すために書き換えるものではありません。

構造 CI ゲート

不変条件の中には、通常のテストでは表現できないものがあります。それが 1 つの挙動の性質ではなく、すべての呼び出し箇所の性質だからです。そうした不変条件は、pytest スイート内の AST レベル / 挙動レベルのゲートによって強制され、Python 3.11 と 3.13 の両方で実行されます:

  • すべての writer が共有書き込みロックを保持していること
  • agent スコープの SQL が isolation 述語を伴っていること
  • identity / dedup のプローブが project 軸と channel 軸を伴っていること
  • check_health がロック保持中に embedding のネットワーク I/O を行わないこと

この種のゲートは、ルールを忘れた呼び出し箇所そのもので失敗します。そこが「たまたま今日の呼び出し箇所を網羅しているテスト」との違いです。

ドキュメント化された事実もゲートされる

手書きの数値は腐ります。ドキュメントに書かれたスキーマバージョン・環境変数の既定値は、それを定義しているソースと突き合わせて検査されます。コードと食い違ったドキュメントは、読み手を誤らせる前に CI で落ちます。

ツールの総数は、そもそも書くことを許していません。検査が届くページでは常に正しく、届かない面 (リポジトリの説明文、レジストリに固定された版ごとのコピー) でだけ古くなっていたので、検査は今では総数の記述そのものを落とします。バージョンの主張はリリースタグと突き合わせて検査されます。

日本語ページは翻訳元の英語コンテンツと突き合わせて検査されるため、翻訳が気づかれないまま原文から遅れることはできません。さらに、すべてのページと nav ラベルは翻訳を持つか「英語のままにする」と宣言するかのいずれかである必要があり、新しいページが翻訳済みサイトの外へ気づかれないまま置き去りになることもありません。

これらのゲートは scripts/ にあります: check-docs-facts.py、check-doc-anchors.py、check-i18n-drift.py、check-i18n-coverage.py。

ミューテーション証明

スイートが緑であることは、テストが走ったことの証明であって、テストが何かに気づいたはずであることの証明ではありません。isolation とロックの不変条件を担っている継ぎ目は CI で意図的に変異させられ、その各変異に対してスイートが赤になることを証明として要求します。変異させても緑のままのゲートは、合格ではなくゲート側の穴として報告されます。

リリースライフサイクル

リリースプロセス自体は RELEASE_LIFECYCLE_STANDARD (v1.0) で規定されており、Cloto 系プロジェクトのリファレンス実装としてここで試行されています。どのラインを動かすべきか、そのラインがいつまで修正を受け取るかは SUPPORT.md にあります。

数字で見る

  • ~24,096 LOC の Python (機能ごとに分割されたモジュール群)、加えて 3,701 行の vendored MCP common スナップショット
  • ~1,862 test functions / ~136 test modules — 挙動マトリクスをパラメータ化すると ~2,476 cases (~54,953 LOC、サーバーコードよりテストコードの方が多い)。上記の構造強制ゲートを含む
  • Schema v13 (自動マイグレーション)
  • MIT License

これらの数値は意図的に概数であり、それ自体もゲートされています。CI でツリーから再測定され、読み手を誤らせるほど乖離した時点で失敗します。