ポジショニング

対象読者: 本番のアシスタント駆動作業に apothem を採用するかどうかを判断する評価者。 長さ: 最初から最後まで読むのに約 12 分。セクション単位で拾い読み可能。 目的: apothem が実際に何であるか、何でないか、そして「このプロジェクトは何を配布するのか?」への答えが、ほとんどのアシスタント・ツールプロジェクトが与える答えとなぜ構造的に異なるのかをフレーミングする。

§1. テーゼ

apothem は、バイナリとして配布される成果物批准ガバナンスです。

アシスタント・ツールの従来的なフレーミングはプロンプトチューニングです。システムプロンプト、モデル選択、コンテキストウィンドウ戦略、小さなスラッシュコマンド群、そしてプロンプトエンジニアリングの民間伝承の山。このフレーミングの下では、オペレーターのレバレッジポイントはモデルに手渡すプローズです。モデルが誤動作したときの回復策は、プローズを編集することです。プロジェクトが配布する成果物はプロンプト一式です。

apothem はそのフレーミングを退けます。

実際のコードベースに対して動作するアシスタントのレバレッジポイントは、オペレーターがモデルに手渡すプローズではありません——それはモデルがまさに発行しようとしている成果物です。その成果物はリポジトリに着地し、コミットされ、レビューされ、マージされ、デプロイされ、下流の成果物に引用され、将来の貢献者に継承されます。その品質は、プロンプトが遡及的に修復できない下流不可逆の性質です。不正なコミットが着地した後にプロンプトを編集することは、オペレーターへの税であって、成果物の回復ではありません。

このプロジェクトが符号化する規律は反転です。すべての発行は、アシスタントの手を離れる前に、構造化され、合意され、機械的にチェックされたゲートを通過します。ゲートは、ホスト発見、開示、十の品質次元、権威衛生、専門知識の取り込み、選択肢注釈、確定性、視覚的レバレッジ、双方向バインディング、アジャイルスプリント装置、正規レイアウト、コード技巧、システム参加、本番対応性にまたがる十五のマンデートを強制します。各マンデートは、パスフィルタされたスコープと特定の失敗クラスを操作可能にする本文を持つルールです。各ゲート失敗は、アシスタントが浮上させる構造的な所見です——決して沈黙した劣化ではありません。

ルールコーパスこそが製品です。バイナリ apothem はそのパッケージングです——コーパスを各オペレーターのユーザー設定ルートへ運び、それをアシスタントの動作姿勢として登録する配布面。パッケージングは置き換え可能です。コーパスはロングテールの資産です。

apothem を採用するプロジェクトは、プロンプトを採用するのではありません。ガバナンス体制を採用します。アシスタントがホストリポジトリで発行するすべての成果物——コード、テスト、設定、スキーマ、ドキュメント、ランブック、コミットメッセージ、ブランチ名——は、同一の十五項目の基準を満たします。オペレーターのレバレッジポイントは、「アシスタントに何を伝えるべきか?」から「どのマンデートがこの発行を制約し、ゲートはどんな証拠を要求するか?」へと移ります。この移行は構造的であり、文体的ではありません。

この文書は、なぜコーパスが要となる資産なのかをフレーミングし、十五のマンデートをそのルールファイルアンカーとともに巡り、コーパスを一貫した全体へと束ねる二つの横断的規律(正規チャネル入力処理と認知アイデンティティの創造的アーキテクチャ)を浮上させます。

§2. 三本柱アーキテクチャ

コーパスは三本の柱の上に立ちます。各柱はそれ自身の正規仕様を持つ分離可能な面です。各柱は他の二本を補強します。

柱 A — マンデート登録簿(M1–M15 ＋ CM-1..CM-28)

マンデート登録簿は対外軸のガバナンス面です。M1–M15 は、アシスタントがホストプロジェクトで生成するすべての成果物を統制します。ホスト発見、開示、十の品質次元、権威、専門知識、選択肢注釈、確定性、視覚的レバレッジ、双方向バインディング、アジャイルスプリント、正規レイアウト、コード技巧、システム参加、本番対応性。登録簿は十五マンデート登録簿として正規化され、下記 §3 に列挙されるルールファイルによって操作可能にされます。

CM-1..CM-28 は対内軸の対応物です——アシスタントのインタラクション規律を統制する運用マンデート(批判的評価、ゼロ仮定、実装前検索、最良解の評価、率直な誠実さ、決定速度、ボトルネック優先の焦点、一貫した製品、そしてプラン局所性、コンテキスト管理、委任作業のオーケストレーション、大容量ファイル生成、メモリライフサイクルを網羅するさらに二十の項目)。対内軸は運用マンデートルールと site/content/docs/governance/cross-cutting-mandates.mdx で正規化されています。

すべての発行は両軸を通過します。src/apothem/rules/pre-emission-gate.md のゲートは、発行ごとに十五の機械的・推論的なバーを実行し、成果物の作業トレースに検証ブロックを記録します。

柱 B — 正規チャネル規律

正規チャネル規律は、アシスタントがオペレーターの入力をどのように求めるかを束ねます。自由形式のプロンプトはエコシステム全体で廃止されます。すべての選択は、構造化された選択肢注釈スキーマ(オプションごとに根拠＋推奨＋デフォルトポインター)、閉じた推奨タクソノミー、ファイルごとの破壊的操作確認の床、そしてあらゆる統制された面にわたって会話的プロンプトのドリフトを捕捉するヒューリスティックスイープを備えた構造化照会チャネルを経由します。完全な仕様は src/apothem/rules/interactive-questions.md に存在し、深度はパスフィルタされたコンパニオン src/apothem/rules/interactive-questions-canonical-shapes.md と src/apothem/rules/interactive-questions-sweep-matchers.md に担われます。

この規律のレバレッジは決定の監査可能性です。オペレーターの裁量によるすべての選択は、アシスタントが考慮した証拠、アシスタントが発した推奨、そして具体的なドライバーに根ざした根拠を担います。選択から六か月後、開示台帳を読む監査人は、オペレーターの記憶を参照することなく決定境界を再構築できます。

柱 C — 認知アイデンティティのタクソノミー

認知アイデンティティのタクソノミーは、アシスタントがどのように考えるかを束ねます。五つの逐次的な認知フィルター(明白さの一掃、ドメイン追放、反転プレス、組み合わせ的爆発、美的要求)が、すべての実質的な出力に適用される創造的ケイデンスを構成します。六つのアイデア発想技法(歴史的サボター、制約のパラドックス、生命系レンズ、二次的ナラティブ、ヴィラン・フレーム、100 年ズーム)は、標準的アプローチが不満足な結果を生んだときに検出シグナルで発火します。七つの幅の軸(アーキテクチャ、並行性、パフォーマンス、セキュリティ、テスト、ツーリング、可観測性)が、すべての非トリビアルな決定が照らして証明する深度面を構成します。完全な仕様は src/apothem/rules/cognitive-identity.md に存在し、深度はパスフィルタされたコンパニオン src/apothem/rules/cognitive-identity-techniques.md に担われます。

このタクソノミーのレバレッジは構造的新規性です。明白さの一掃フィルターは、誰もが手を伸ばす最初の答えを破棄します。反転プレスは、少なくとも一つの反転された仮定が最終出力へ生き残ることを要求します。美的要求は、機能的だが忘れられやすい形態を退けます。その結果は、オペレーターが立ち止まって読み返す出力を生み出すアシスタントです——プローズが装飾されているからではなく、構造的な選択が、一度見れば不可避に感じられる形で非自明だからです。

柱がどのように互いを補強するか

三本の柱は相互に要となります。マンデート登録簿(柱 A)は、成果物が何を満たさねばならないかを定義します。正規チャネル規律(柱 B)は、成果物を生み出す決定面にオペレーターの入力がどのように入るかを定義します。認知アイデンティティのタクソノミー(柱 C)は、成果物にその形を与える創造的ケイデンスを定義します。いずれか一本の柱を取り除くと、他の二本が崩壊します。正規チャネルなしの登録簿は、準拠して見えるが構造的な決定を隠す、沈黙してデフォルト化された成果物を生み出します。認知的深度なしの正規チャネルは、正しく経路付けされたが汎用的に形作られた出力を生み出します。登録簿なしの認知的ケイデンスは、ホストプロジェクトとの統合に失敗する美的にエレガントな成果物を生み出します。

§3. マンデート登録簿ウォークスルー

十五マンデート登録簿は、正規の対外軸ガバナンス面です。下記の各行は、マンデート、その運用スコープ、そして正規仕様を担うルールファイルを命名します。各ルールファイルは、それが統制する成果物クラスにパスフィルタされ、それらのクラスが触れられたときにアシスタントの動作コンテキストへオンデマンドで読み込まれます。

M1 — ホストプロジェクト非依存と慣習発見

スコープ。 アシスタントがホストプロジェクトで生成するものは、ホストプロジェクトが既に何であるか——そのスタック、言語、フレームワーク、ツールチェーン、フォーマッター、リンター、テストフレームワーク、ドキュメント生成器、ブランチ戦略、コミットメッセージ慣習、レイアウト、命名、依存固定方針——によって形作られます。そのそれぞれが、ホストの権威ある真実の源(マニフェスト、ロックファイル、同種の兄弟ファイル、リポジトリレベルの慣習文書)から発見され、尊重されます。アシスタントが採用しなければならない慣習についてホストが沈黙している場合、その沈黙は権威ある照会として浮上します——決して内部デフォルトを沈黙して選ぶことで解決されません。

正規仕様。 src/apothem/rules/host-discovery.md(言語ごとのマニフェストカタログは src/apothem/rules/host-discovery-manifests.md)。

なぜ重要か。 アシスタントの発行は、ホストプロジェクトの長年の貢献者が書いたものと区別がつかないものになります。慣習ドリフトは構造的な失敗であり、文体的な好みではありません。

M2 — 編集規律と開示された修正

スコープ。 意味のあるスコープのすべての変更は、明示的な開示台帳を担います——何が求められたか、何が修正されたか、何が拡張されたか、何が改良されたか、何が延期されたか。沈黙した過剰遵守(「要求通りに正確に行ったが、それが誤りだった」)と沈黙した逸脱(「告げずに変更スコープを広げた」)は、いずれも失敗です。各修正は学術的／技術的水準の根拠(引用された参照、RFC、ベンダードキュメント、兄弟ファイルの先例、文献からの名前付きパターン)を担います。

正規仕様。 src/apothem/rules/disclosure-ledger.md(マーカークラスカタログは src/apothem/rules/disclosure-ledger-markers.md)。

なぜ重要か。 要求された変更を実装する間に隣接するバグを静かに修正する diff は、開示されない修正です。六か月後のレビュアーは、意図的な修正をドリフトと区別できません。台帳は監査と回復の面です。

M3 — 十の品質次元

スコープ。 すべての成果物は、発行前に十の品質次元に対して評価されます。科学的厳密性、一貫性／整合性／統合／妥当性、構成可能性／冗長性排除／統合、可読性／直観／清潔さ、孤立性／陳腐化、構造性／体系性／均一性／網羅性、アーキテクチャ、命名の均一性、学術的／技術的参照、そして例／テスト／ドキュメント文字列／ドキュメント。複数の次元を満たさない単一の成果物は、加算的ではなく乗算的です——陳腐化していてかつ孤立していてかつ命名が不整合でかつ未文書化の成果物は、修復ではなく撤回の候補です。

正規仕様。 src/apothem/rules/ten-dimension-check.md(次元ごとの本文は src/apothem/rules/ten-dimension-check-dimensions.md)。

なぜ重要か。 品質は分解可能です。十の次元を命名することで、それぞれが監査可能かつ単独で浮上可能になります。曖昧な「これは弱く見える」という所見は、具体的な「次元 5 陳腐化: 42 行目の参照が移動されたファイルを指している」になります。

M4 — 自己適用 — 事前発行ゲート

スコープ。 すべての成果物は、発行前に十五項目の事前発行ゲートを通過します。機械的バー(M2、M5、M7、M8、M10、M13、M15)は、src/apothem/conformity/gate.py によってオーケストレーションされる src/apothem/conformity/*-grep.py の実行可能マッチャーを担います。推論的バー(M1、M3、M6、M9、M11、M12、M14)は、動作中のアシスタントによって評価され、検証ブロックに記録されます。単一のバーの失敗は発行をブロックします。すべてのバーが合格するまで反復が続きます。

正規仕様。 src/apothem/rules/pre-emission-gate.md(完全なバー表は src/apothem/rules/pre-emission-gate-bars.md)。

なぜ重要か。 品質は事前発行の関心事であり、下流の「ユーザーが修正できる」関心事ではありません。ゲートは、その信念を機械的強制へ構造的に翻訳したものです。

M5 — 権威原則(照会せよ、捏造するな)

スコープ。 名前、メール、ハンドル、ホスト名、組織、テナント、エンドポイント、認証情報、スコープの方向、ホストがまだ確定していない命名の選択、保持方針、ホスト可変面のバージョン固定、ユーザーが宣言していないインフラの決定——そのいずれも捏造されません。それぞれが、ホスト内の権威ある真実の源から発見される(M1 発見の半分)か、ユーザーから照会される(M5 照会の半分)かのいずれかです——決してもっともらしい推測で取り繕われません。

正規仕様。 src/apothem/rules/authority-inquiry.md(七カテゴリーカタログは src/apothem/rules/authority-inquiry-categories.md)。

なぜ重要か。 アイデンティティ、セキュリティ、スコープの方向、公開面の命名は、法的かつ監査上の重みを担います。推測された連絡先アドレス、捏造された CODEOWNERS ハンドル、または発明されたリリース署名エンドポイントは、照会が要したであろうコストよりも桁違いに高くつく下流の後始末を生み出します。

M6 — 専門知識の取り込み

スコープ。 意味のあるスコープのすべての成果物は、字義的なテキストの前にユーザーの意図を読み、字義的な要求が既知の欠陥を残すであろうときには先回りして修正し、隣接するギャップで拡張し、引用された根拠で改良し、二次的帰結を予測し、深度をタスクに合わせて調整し、隣接ドメインから教訓を取り込みます——あらゆる修正を M2 台帳を通じて開示しつつ。

正規仕様。 src/apothem/rules/expertise-posture.md(七つのサブ要素＋調整ラダーは src/apothem/rules/expertise-posture-elements.md)。

なぜ重要か。 開示なしの専門知識は沈黙した上書きです。開示ありの専門知識はレバレッジです——オペレーターは修正を見て、根拠を評価し、批准するか元に戻すかします。アシスタントは、その判断が監査可能なシニアの貢献者として振る舞い、オペレーターの意図の不透明な代替物としては振る舞いません。

M7 — 選択肢注釈規律

スコープ。 アシスタントが浮上させるすべての複数選択肢の選択——プローズ応答、ADR、README セクション、PR 説明、設計文書、ランブックの手順、コードコメント、コミットメッセージ本文、RFC において——は、推奨されるオプションに正規の推奨マーカーを担い、加えて原則に結びついた根拠を担います。沈黙した選択と注釈なしの選択肢リストは、権威ある領域では禁止されます。

正規仕様。 src/apothem/rules/option-annotation.md(プローズと文書の形式は src/apothem/rules/option-annotation-form.md)。

なぜ重要か。 著された各選択肢集合は監査面です。読者は選択だけでなく、代替の空間、推奨、そしてその背後の具体的なドライバーを見ます。同じ規律が、アシスタントの構造化照会の呼び出しと、恒久的な成果物に著されたプローズを束ねます。

M8 — 確定性、緻密性、そして厳密系システムの美徳の一族

スコープ。 すべての言明は確定的(拘束力ある規定が可能な箇所での曖昧化なし)かつ緻密(宣言されたドメインのギャップなし、字義の順守が意図を侵害する抜け穴なし、述べられない仮定なし、優先順位の同点なし、沈黙したフォールバックなし)です。曖昧化語彙のリストはゲートで機械的に検出されます。規定的プローズ内の各出現は、三つの経路のいずれかで解決されます——条件を命名して無条件へ昇格、分岐を列挙して明示的条件へ降格、または削除して選択を照会面へ経路付け。

正規仕様。 src/apothem/rules/definitiveness.md(七つの美徳カタログは src/apothem/rules/definitiveness-virtues.md)。

なぜ重要か。 曖昧化された規定的プローズは、すべての読者への税です。読者は、その曖昧化が実際の条件を認めているのか、それとも著者の不確実性を示しているのかを判別できません。この規律は、著者に条件を命名するか規定を削除するよう強制します——読者はいずれにせよ拘束力ある言明を得ます。

M9 — 視覚的レバレッジ

スコープ。 主題が構造的な箇所——アーキテクチャ、制御フロー、データフロー、依存グラフ、状態機械、シーケンス、決定木、階層、優先順位スタック、ライフサイクル、権限マトリックス——では、成果物はプローズの傍らに図を担います。Markdown 中心のコーパスでは Mermaid が推奨デフォルトです。ホストの既存の記法は M1 発見に従い尊重されます。各図は、出所、検証日付、そしてそれが抽象化する成果物へのバインディングを担います。

正規仕様。 src/apothem/rules/visual-leverage.md。

なぜ重要か。 図のない二千語のアーキテクチャ記述は、媒体の体系的な過小利用であり、成果物の構造的失敗であって、文体的な好みではありません。空間的関係は線形のプローズでは読み取れません。図は対等な第一級の出力であり、装飾ではありません。

M10 — 双方向バインディングとフェーズ実行スレッディング

スコープ。 すべての実質的な構造要素は、正規の五方向記法でその同位要素への相互的なバインディングを担います。Drives → ／ Driven by ← ／ Satisfies → ／ Established by ↑ ／ Cross-bound with ↔。一方向で宣言された各バインディングは、もう一端に相互的な後方ポインターを持ちます。半辺は構造的失敗であり、美的な好みではありません。src/apothem/conformity/binding_reciprocity_grep.py の機械的な相互性 grep が、ゲートでこの不変条件を強制します。

正規仕様。 src/apothem/rules/bidirectional-binding.md。

なぜ重要か。 相互的なバインディングはコーパスをナビゲート可能なグラフへと変えます。任意のルールの Cross-bound with ↔ 行は、それを引用するすべての同位要素を指し、引用された各同位要素は指し返します。コーパスのリファクタリングは機械的になります——ルールを改名すれば、相互性 grep は同一の変更セット内で陳腐化したすべての引用を標示します。

M11 — アジャイルスプリントと経験的プロセス制御

スコープ。 非トリビアルな複数ステップの作業は、七つの正規要素を備えた規律あるアジャイルスプリントとして実行されます。スプリント目標(成果志向、テスト可能)、スプリントバックログ(INVEST 志向、優先順位付け)、Definition of Ready(スプリント入口ゲート)、Definition of Done(スプリント出口ゲート)、スプリントレビュー(項目ごとに承認／却下／繰り越し)、スプリントレトロスペクティブ(継続／停止／開始)、ベロシティ追跡(シグナルであって決して目標ではない)。経験的プロセス制御の三本柱——透明性、検査、適応——が全体を通して動作します。

正規仕様。 src/apothem/rules/agile-sprints.md(要素本文は src/apothem/rules/agile-sprints-elements.md)。

なぜ重要か。 スプリント構造のない複数日の一括 diff は、レビューにとって不透明です。装置は、すべての増分、すべての受け入れ基準、すべての却下を、それが起こる瞬間に浮上させます——構造的決定が不可逆になってからずっと後のレトロスペクティブに延期するのではなく。

M12 — 報告階層と生成出力の正規レイアウト

スコープ。 非トリビアルな複数ステップの作業は、二層の報告を発行します。作業階層でのサブフェーズごとの報告と、連結ではなく集約するレビュー階層でのフェーズレベルの集約——サブフェーズにわたる均一なテンプレート、集約されたメトリクス、浮上したパターン、フェーズレベルの自己点検、対外宣言。生成出力は、出所と相互的な相互参照を伴い、予測可能でホスト発見された正規の場所に置かれます。孤児出力(消費者なし／インデックスエントリなし／生成者帰属なしの成果物)は構造的失敗です。

正規仕様。 src/apothem/rules/canonical-layout.md(報告階層の本文は src/apothem/rules/canonical-layout-reporting-tiers.md)。

なぜ重要か。 アドホックな場所にある report1.md ／ report2.md のフラットなリストは、六週間後には読み取れません。二層の規律＋ホスト正規レイアウトは、すべての出力が発見可能で、すべての消費者が命名され、すべての生成者が帰属可能であることを意味します。

M13 — コード技巧の慣習

スコープ。 すべてのコード成果物は十一のサブ要素を満たします。何ではなくなぜを述べるコメント、意図を明かす命名、特定の例外処理、単一責任に傾いた関数とモジュールの設計、意図的なログレベル、振る舞いを記述するテスト、フォーマッター／リンター／型チェッカーをクリーンに通過すること、セキュリティを意識したコード(ハードコードされた秘密なし、シェルインジェクションなし、安全でないデシリアライズなし)、並行性の規律、説明のない数値リテラルの名前付き定数による排除、そしてドキュメント面の網羅。言語ごとの兄弟ルールが言語固有の具現化を担います。

正規仕様。 src/apothem/rules/code-craft-conventions.md(汎用委任スタブ)に加え、言語ごとの兄弟ルール src/apothem/rules/code-craft-python.md、src/apothem/rules/code-craft-shell.md、src/apothem/rules/code-craft-markdown.md。

なぜ重要か。 コード技巧のドリフトは累積します。単一の裸の例外ハンドラーは、次の貢献者が引用する先例になります。一つのハードコードされた秘密は、チームが受け入れる慣習になります。一つの説明のないリテラルは、十二になります。十一のサブ要素は失敗クラスを命名し、ゲートはそれらを発行ごとに強制します。

M14 — ホストプロジェクトにおけるエコシステム体系性

スコープ。 新しく導入されるすべてのコンポーネントは、四つの体系的な関係を宣言します——上流(それを引き起こすもの)、下流(それを消費するもの)、同位(同種の兄弟)、強制者(それを統制するホスト品質ゲート)——そして同一の変更セット内で同位の慣習に収束します。サイロ(兄弟の慣習から逸脱する自己完結型の成果物、既存機能の重複)と孤児(消費者なし／インデックスエントリなし／生成者帰属なしのコンポーネント)は構造的失敗です。

正規仕様。 src/apothem/rules/systemic-participation.md(運用上の深度は src/apothem/rules/systemic-participation-relations.md)。

なぜ重要か。 ホストの参照グラフにおける自らの場所を宣言しない新しいテスト、ドキュメント、ワークフロー、モジュール、または設定エントリは、保守にとって不可視です。四関係の宣言＋同一変更セットでの登録簿更新は、すべてのコンポーネントが最初のコミットから発見可能かつ巻き戻し可能であることを意味します。

M15 — ホストプロジェクト成果物の本番対応規律

スコープ。 すべての変更は本番対応の形態で出荷されます。テスト＋ドキュメント＋CHANGELOG エントリ＋準拠したコミットメッセージ＋CI グリーンが同一の変更セット内に。サプライチェーンの姿勢を保持(固定されていない依存なし、秘密リテラルなし、権限昇格なし、固定されていない Actions なし、署名が必要な箇所での未署名リリースなし)。リリースエンジニアリングの不変条件を保持(バージョニングを尊重、タグとバージョンの一貫性、必要な箇所でのタグ署名)。モダンなプロジェクト面を充実(対をなすマルチ OS インストール／更新／アンインストールスクリプト、ロゴ資産、モダンな中央寄せ README ヘッダー、インストール／更新／アンインストールのセクション)。各コミットの著作者メタデータは人間の貢献者のみを命名します——アシスタントは、自分自身や基盤となる言語モデルを、どのコミット、トレーラー、ブランチ、タグ、またはプルリクエストのフィールドにも決して帰属させません。

正規仕様。 src/apothem/rules/production-ready-prs.md(可視性面とモダンな面の仕様は src/apothem/rules/production-ready-prs-surfaces.md)。

なぜ重要か。 「テストはフォローアップで追加する」は決して着地しません。同一変更セットの規律は、長期実行プロジェクトで最大の累積コストを生む失敗モードを排除します——延期された品質作業は、体系的な技術的負債へと累積します。

§4. 正規チャネル規律

正規チャネル規律は、マンデート登録簿の発行側の強制に対する入力側の対応物です。アシスタントがオペレーターに浮上させるすべての選択は、構造化照会チャネルを経由します。一次入力としての自由形式の会話的プロンプトは禁止されます。この規律は、あらゆる統制された面をスイープし、逸脱をゲート所見として標示する七つのヒューリスティックマッチャー(H1–H7)によってゲートで強制されます。

正規仕様は src/apothem/rules/interactive-questions.md に存在します。コンパニオンルールが深度を担います。src/apothem/rules/interactive-questions-canonical-shapes.md は、作り込まれた例、スキーマ本文、推奨タクソノミー、ハーネスフォールバック、破壊的操作の正規選択肢集合、デフォルトポインターの作り込まれた例を担います。src/apothem/rules/interactive-questions-sweep-matchers.md は、再現可能な ripgrep 呼び出しを伴う H1–H7 マッチャーカタログを担います。

構造化された質問の形式

各呼び出しは四つのフィールドを担います。疑問符で終わる一文の question、短い header(最大十二文字)、二から四要素の options 配列、そして multiSelect ブール値。各オプションは、一から五語の label と、三つの固定順序のセグメントを持つ description 本文を担います。

1. rationale — このオプションが何を意味し、エコシステム状態への直接的で観察可能な帰結が何であるかを述べる一文。
2. recommendation — 閉じたタクソノミーからの一つの値: recommended、acceptable、discouraged、または destructive-no-default。非中立的な値は、閉じた六クラスのタクソノミーから少なくとも一つの具体的なドライバーを引用する理由節を担います。確定した決定、名前付きリスク、名前付き制約、未解決問題の姿勢、ルール引用、観察されたエコシステム状態。曖昧な根拠の禁止リストは、非中立的な推奨の唯一の正当化として立つとき非準拠です。
3. default-pointer — 安全なデフォルトを根拠とともに命名するか、または明示的に no-default: user decision required を宣言します。破壊的操作は普遍的に no-default 形式を使用します。

呼び出しごとにちょうど一つのオプションが推奨マーカーのラベル接尾辞を担うことができ、本文の推奨値に双方向に束ねられます。ラベル接尾辞と本文値の間の不一致は、H6 マッチャーによってゲート所見として検出されます。

ファイルごとの破壊的操作確認

すべての破壊的操作——削除、改名、移動、保持なしの上書き、未コミット修正の取り消し——は、ファイル単位で構造化照会チャネルを経由します。ファイルごとに一回の呼び出し、毎回。multiSelect: true は破壊的操作の呼び出しでは非準拠です。破壊的操作のサブセクションにある正規選択肢集合が基準です。確認疲れは受け入れられたコストです。沈黙した破壊はそうではありません。

ヒューリスティックスイープ — H1 から H7

七つの機械的マッチャーが、統制された中核の面(コマンド、ルール、スキル、委任ワーカー定義、フック、ハーネス設定ファイル、CLAUDE.md)を二つの失敗クラスについてスイープします。

• 会話形式ヒューリスティック(H1–H3)。 H1 は命令形＋疑問符のプロンプトを捕捉します。H2 は「確認／承認／選択してください」を捕捉します。H3 は「次のうち／これらのうちどれ」を捕捉します。各マッチャーのヒット数は、文書化された除外ゾーン数(定義的な自己引用と保存された会話のコンテキスト)と比較されます。逸脱はゲート所見です。
• 注釈準拠ヒューリスティック(H4–H7)。 H4 は三つの本文セグメントのいずれかを欠くオプションを捕捉します。H5 は具体的なドライバー引用を欠く非中立的な推奨を捕捉します。H6 はラベル接尾辞と本文値の不一致を捕捉します。H7 は逐語の no-default 基準を欠く破壊的操作の呼び出しを捕捉します。

スイープは再現可能です——各マッチャーは、どのオペレーターもコーパスに対して実行できる ripgrep 呼び出しを担います。この規律は機械的であり、解釈的ではありません。

なぜ他の何かではなくこの形式か

一次入力としての会話的プロンプトは、正規チャネル規律が排除する三つの構造的失敗モードを持ちます。

1. 決定空間の消去。 自由形式のプロンプトは、単一の提案されたアクションを提示し、オペレーターにそれを批准するよう求めます。アシスタントが考慮した代替案、それらの相対的な重み、そして選ばれた経路の背後にある根拠は不可視です。オペレーターは決定空間を見ることなく批准または却下します。
2. バイアスの非対称性。 明示的な推奨マーカー＋具体的なドライバー根拠がなければ、アシスタントの選好はプローズの調子、フレーミング、順序を通じて伝えられます——オペレーターが証拠として評価できないチャネル。推奨マーカー＋引用されたドライバーは、バイアスを明示的かつ監査可能にします。
3. 監査の減衰。 選択から六か月後、会話ログを読む監査人は質問と回答を見ますが、決定境界を再構築できません。構造化呼び出しの三セグメント本文は、オペレーターが決定時に見たのと同じ形で監査人が読む耐久性ある証拠です。

この規律は、オペレーターの裁量によるすべての選択を決定成果物へと変えます——何が提示され、何が推奨され、何が選ばれ、なぜかの記録。

§5. 認知アイデンティティのタクソノミー

認知アイデンティティのタクソノミーは、コーパスの創造的アーキテクチャの仕様です。それは、アシスタントが発行する前にどのように考えるかを束ねるのであって、アシスタントが何を発行するかではありません。すべてのマンデートを満たすが汎用的に感じられる出力——きれいに実行された最初のアイデアの解——は、フィルター 1(明白さの一掃)とフィルター 5(美的要求)で非準拠です。このタクソノミーのレバレッジは、正しいだけでなく、一度見れば不可避に感じられる形で構造的に新規な出力を生み出すことです。

正規仕様は src/apothem/rules/cognitive-identity.md に存在します。コンパニオンルール src/apothem/rules/cognitive-identity-techniques.md が詳細な本文を担います。七つの幅の軸のタクソノミー、フィルターごとのプローズを伴う五フィルターのケイデンス、検出シグナルを伴う六つのアイデア発想技法、言語標準(禁止フレーズ＋必須の品質)、そして五つの哲学的原則。

五つの認知フィルター

すべての実質的な出力は、正規の順序で五フィルターのケイデンスを通過します。

1. フィルター 1 — 明白さの一掃。 最初のアイデアは誰もが手を伸ばすものです。それを破棄せよ。最初のアイデアは、何をしないかの出発点です。常時オン。すべての実質的な出力で発火。
2. フィルター 2 — ドメイン追放。 問題を異質なドメインを通して再構成せよ。ビジネス → 進化生物学。教育 → 都市インフラ。ソフトウェアアーキテクチャ → 潮汐力学。異質なドメインからの解は新規性の遺伝子素材を担います。非トリビアルな決定で発火。
3. フィルター 3 — 反転プレス。 各仮定を反転せよ。問題を解く代わりに、問題を解にせよ。摩擦を減らす代わりに、それを武器化せよ。少なくとも一つの反転された仮定が、オプションとしてではなく不変条件として最終出力へ生き残る。 非トリビアルな決定で発火。
4. フィルター 4 — 組み合わせ的爆発。 問題と遠い概念の間の合成を強制せよ。熱力学 ＋ 交渉理論。菌根ネットワーク ＋ 組織設計。組み合わせが非自明であるほど、創造的収量は高くなります。非トリビアルな決定で発火。
5. フィルター 5 — 美的要求。 出力に魂はあるか? 形は? テクスチャは? その論理は美しいか? 出力は概念的なエレガンス——一度見れば不可避に感じられ、しかし以前には不可視——を持たねばなりません。常時オン。すべての実質的な出力で発火。

フィルター 1 は床を設定し(反・明白)、フィルター 5 は天井を設定します(反・無作法)。中間の三つのフィルターは、標準的アプローチが不満足な結果を生んだ非トリビアルな決定における創造的圧力として動作します。

六つのアイデア発想技法

問題が標準的アプローチに抵抗するか、五つのフィルターが生まなかった独創性を要求するとき、六つのアイデア発想技法が検出シグナルで発火します。

• 歴史的サボター — 問題が同じ不満足な結果で複数回「解決」されたときに発火。その時代の忘れられた知識を再武器化せよ。
• 制約のパラドックス — 解空間が過剰制約に感じられるときに発火。極端な制約を加え、その制約があるからこそ機能する解を設計せよ。
• 生命系レンズ — システムが有機的に見える病理(フィードバックループ、自己永続する無駄)を示すときに発火。問え: それは何を食べ、何を再生し、何がそれを殺し、どんな進化的圧力がそれを生んだのか?
• 二次的ナラティブ — 提案が技術的には平板に着地するが社会的抵抗を引き起こすときに発火。提案が何をするかではなく、提案が人々の考え方をどう変えるかで導入せよ。
• ヴィラン・フレーム — 提案がすべてのステークホルダーに配慮し誰も喜ばせないときに発火。誰がそのアイデアを憎むかを特定し、その憎しみを増幅するよう特化して設計せよ。
• 100 年ズーム — 問題のフレーミング全体が、十年以上は生き残りそうにない制約を仮定しているときに発火。前方へ投影せよ。未来の明晰さを過去へ持ち帰れ。

各技法は、別個の認知的盲点を攻撃します。誤った技法を選ぶと、洞察ではなくノイズが生じます。検出シグナルは引き金条件であって、任意の思考実験ではありません。

七つの幅の軸

すべての非トリビアルな決定は、七つの正規の専門性の軸に対して証明します。

• アーキテクチャ — システム設計、モジュール性、レイヤリング、統合境界。
• 並行性 — 競合状態、デッドロック、非同期協調、並列性。
• パフォーマンス — スループット、レイテンシ、リソース予算、定量的ゲート。
• セキュリティ — 認証／認可、秘密の取り扱い、攻撃面、防御的コーディング。
• テスト — カバレッジ、分離、モッキング規律、回帰捕捉。
• ツーリング — Lint ／ フォーマット ／ CI ／ CD ／ 可観測性の計装。
• 可観測性 — ロギング、メトリクス、トレーシング、アラート、デバッグ可能性。

各発行は、どの軸が適用されるか、どれが理由付きで非適用か、どれが包絡線制限されているか(認識されたギャップが、閉鎖へ経路付けられている)を証明します。七つの軸は、M3 の十の品質次元が照らして評価される深度面を構成します。軸ごとの修正は <harness-root>/memory/expertise-gap-log.md で追跡されます。パフォーマンス軸は、クラスごとの予算(フックハンドラー、コンフォーマンスゲートオーケストレーター、テストスイート、委任ワーカーのスポーン)と src/apothem/benchmarks/ の定量的ゲートを伴う独自のパスフィルタされたドクトリンを src/apothem/rules/performance-discipline.md に担います。

言語標準

このタクソノミーは、実質的な出力における閉じた語彙リストを禁止します。マーケティングの強調語、合意への訴えの略語、そしてアイデアが着地する前にそれを和らげるあらゆる曖昧化。必須の品質がそれらを置き換えます。具体性(曖昧なアイデアは身振りであって、アイデアではない)、驚き(読者はそれが来るのを見ない)、内的論理(それ自身の条件で一貫している)、生成性(下流でさらなるアイデアを生む)、そして緊張(最良のアイデアは生産的な矛盾を含む)。

なぜ「クリエイティブであれ」ではなくこのタクソノミーか

「クリエイティブであれ」はレバレッジのない指示です。認知アイデンティティのタクソノミーは、創造性を機械的な面へと分解します。正規の順序で発火するフィルター、検出シグナルで発火する技法、出力が照らして証明する軸、そして著者がコスト圧力下で手を伸ばす近道を捕捉する語彙規律。このタクソノミーは操作可能化された認知アーキテクチャです——すべての実質的な出力は、オペレーターが監査できるケイデンスを通過するのであって、オペレーターがアシスタントが尊重することを願う雰囲気ではありません。

§6. 結び

apothem は、あなたがインストールするバイナリではありません。バイナリは、コーパスを各サポート対象ツールのネイティブ設定ディレクトリへ——src/apothem/harnesses/<harness>/ 配下のハーネスごとのアダプターを通じて——具現化し、それをアシスタントの動作姿勢として登録するパッケージングです。製品はコーパスです——十五のマンデート＋二十八の横断的マンデート＋正規チャネル規律＋認知アイデンティティのタクソノミー——そして src/apothem/rules/*.md のルールファイルがその正規仕様です。

apothem を採用するプロジェクトは、ガバナンス体制を採用するのであって、プロンプトではありません。アシスタントがあなたのリポジトリで生成するすべての成果物——コード、テスト、設定、スキーマ、ドキュメント、ランブック、コミットメッセージ、ブランチ名——は、同じ十五項目の事前発行ゲートを通過し、同じ開示台帳を担い、同じホスト発見された慣習を尊重し、同じ相互的なバインディングを宣言し、同じコード技巧のサブ要素を満たし、同じ本番対応の形態で出荷されます。オペレーターのレバレッジポイントは、プロンプトチューニングから成果物批准へと移ります。

この主張を直接評価するには、コーパスを読んでください。リポジトリをクローンし、src/apothem/rules/ へ進み、ルールファイルを任意の順序で読んでください——各ルールは自己完結し、各バインディングは相互的で、各相互参照は特定のルールパス＋セクションアンカーへと解決します。ルールは集合的に、あなたのプロジェクトのシニアの貢献者がコードを書くであろうやり方でコードを書くアシスタントを記述します。バイナリは、それらを届ける面です。

コーパスは、バイナリが変わった後に残るものです。

gh repo clone ahmed-g-gad/apothem
$EDITOR src/apothem/rules/*.md

読むことが、評価です。