modus-reinit

modus-reinit は何をしますか？

既存の本文を全量レビューする際に使用します。証拠ガイド、生成フレームワーク、公開契約を共有します。本ファイルは reinit の差分のみを記述します。

まず棚卸し、それから変更の証明

既存の本文とハッシュを完全に読み取り、ターゲットを unchanged、anchor-only、implementation-change、scope-change、content-repair、退役の疑い、または手動作成本文に分類します。安定した識別子と主定義はデフォルトで再利用します。ソースパス/シンボルの移動はアンカーのみを修正し、本文レイアウトの変更はスコープ変更ではありません。

content-repair には以下が含まれます：汎用テンプレート段落による実際のシナリオの置き換え、代表アンカーによる事実の置き換え、モジュール間のコピー、完了/失敗の意味の曖昧さ、複雑な関係を理解するのに役立つ図の欠如。読者のタスクを真に満たし事実が変わらない本文は unchanged としてスキップし、書き込みを省略します。

実行

1. 単一リポジトリで今ラウンドの証拠を同期的に構築し、reinit-diff コンテキストを取得します。失敗したらすぐに現在のソースコードに戻します。機械証拠契約に従って方向付け展開を行い、バンドル内部ファイルを直接読み取ったり、カーソルを消耗したりしません。
2. スコープモデリングに従い、「安定した識別子→エントリ/オブジェクト責任→セマンティック変更→構造変更→ファイル変更」の順で判断し、スコープ、ハンドル、読み取り時ハッシュ、正確なDomain/Module evidence/status、Domain coverage、アウトカム、図の候補を一意のschemaVersion: 2実行カードに書き込みます。新規追加、分割、統合、移動、名前変更、または退役の証明済みもののみを統合確認します。デフォルトは逐次実行。ユーザーの明示的な承認があり、互いに重複しない複数の影響を受けるDomainが存在する場合、Domainごとの並行作成をロードし、Domain worker委任契約を使用します。ルート作成者は引き続き実行カードと共有成果物を独占します。
3. 各変更または content-repair Moduleに対して、正確なセレクタで module-authoring コンテキストを要求し、二重サマリと requestedScope を照合します。ドメイン全体の複数の独立したModuleをカバーする幅広い要求は無効です。互いに依存しない要求は並行して実行可能で、その後現在のDomainのソースパス/シンボルを集約・重複排除し、バッチで再読み取りします。要求が失敗、空結果、または部分的な場合は現在のメソッド本体、設定、SQL、テストに戻って補完し、クラス名、インターフェースシグネチャ、ファイル先頭行のアンカーをコンテンツ復元の証拠として使用してはいけません。異なるトピックのために同一リンクを再スキャンしてはならず、同一本文に並行して書き込んではいけません。シナリオクロージャーに従って再証明します。元の主定義で改訂し、changelogを追加せず、テンプレート変更による一括書き換えや再描画は行いません。
4. 完全なDomainバッチとして、「6トピック主定義→Moduleシナリオ→Domainルーティング」の順で影響範囲を読み戻します。ソースパスと行番号は各生成ドキュメントのfrontmatter内の少数のanchors.locationsに移行し、本文からは完全なソースパス、path#L、証拠リストを削除します。修復の目標は、完全なタスク、フィールドセマンティクス、重要な分岐、ステータス、エラー復旧を復元することで、ファイルにタイトル、アンカー、または類似の長さを再付与することではありません。証拠が閉じられた後、図とテキスト表現に従って候補を再評価し、唯一の主図を更新します。ナビゲーションテーブルは説明図の代わりになりません。Domainレベルのcoverage-auditは、このDomainのcandidate/capability/source path/symbolスコープを再利用する必要があり、modus/knowledge/**を使用してはいけません。no-match、空結果、または部分的なものは、補完または明確なギャップの特定のみをトリガーします。有効な結果をDomain coverageとして記録し、3種類の読者のリードバック完了後、ルート作成者が実際のファイルを読み取りreviewedをマークします。クロスドメイン方向、所有権、ステータス、条件、完了、または復旧の変更があった場合のみルート概要を更新します。Team Standardと既存のbusinessはデフォルトで元のバイトを保護し、新しいDomainにはmodus knowledge seed-business --domain <slug> --jsonを使用して欠落インデックスを作成します。
5. 構造変更は、新しい配置先に書き込んでからセマンティックリードバックを行い、生成本文の入リンクとナビゲーションを修正し、読み取り時ハッシュを使用して古い生成ファイルを削除します。シンボルの消失、partial、カバレッジギャップから直接退役を推測してはいけません。
6. グローバルセマンティックリードバック後、modus knowledge verify --publication --json を実行し、CAS公開とリードバックを行います。publicationは、schemaVersion: 2実行カード、本文内のソースパスなし、構造化アンカー、Moduleごとのevidence、Domain coverage、visual決定を確認する必要があります。clean はまだ本文品質の証明になりません。同程度の長さの短文が多数ある、実際のシナリオがない、ナビゲーションテーブルのみ、ステータストピックに変換がない、またはevidenceがファイル先頭行にしかない場合は、引き続き改訂します。実行カードを事前に削除してはいけません。また、紛失後に出力に基づいてより小さな「すべてreviewed」カードを再構築してはいけません。すべてのターゲットが終了状態に達し、セマンティックリードバック、実際のpublication、および公開後リードバックがすべて成功した場合のみ実行カードをクリーンアップします。通常の機械検証はpublicationの代わりになりません。実際のレポートは、unchanged、改訂、削除、競合、ギャップを報告します。