Urazuke — 進化・修正の道：方法で生まれなかったシステムを正常化し、それからはしごを登る

We are going to assess whether this existing system can be taken over with the Urazuke method, with prerequisites that you verify by doing, not by asking. Read the initial survey in docs/INITIAL_SURVEY.md and the criteria sheet in docs/ELIGIBILITY_CRITERIA.md. Then, changing nothing in the system, verify each prerequisite with evidence: (1) try to set up a complete environment of the system from the repository and a copy of the data, with its sources, data model and persistence, and tell me exactly what you could and could not bring up; (2) read the whole code and tell me whether you can understand and work with it, module by module, naming what you cannot understand; (3) from the code alone, write docs/FUNCTIONALITY_RECOVERED.md: the complete functionality of the system described for an end user, screen by screen and process by process, marking what you inferred; (4) list every screen and say whether it can be driven by a test tool with each element accessible and the backend effect checkable, and prove it by writing and running one end-to-end test of one flow; (5) try to build and run the system from the sources with today's tools and report every dependency that does not resolve; (6) check whether the production data can be copied and anonymized into a test environment and whether a backup exists and has ever been restored; (7) list every external integration and say whether it has a test mode or can be isolated at the edge. For each prerequisite: green or red, the evidence (what you did and what happened), and, if red, what project would make it green. Do not decide: present me the sheet, and I decide. Reply in my language.

この既存システムをUrazukeの方法で引き受けられるかを、あなたが聞くのではなく実際に行って検証する前提条件で評価します。docs/INITIAL_SURVEY.md の初期調査と docs/ELIGIBILITY_CRITERIA.md の基準シートを読んでください。その後、システムの中の何も変えずに、各前提条件を証拠とともに検証してください：(1) リポジトリとデータの複製から、ソース、データモデル、永続化を含むシステムの完全な環境を立ち上げようと試み、何を立ち上げられて何が立ち上げられなかったかを正確に教えてください。(2) コードを丸ごと読み、それを理解して扱えるかをモジュールごとに、理解できないものの名前を挙げながら教えてください。 (3) コードだけから docs/FUNCTIONALITY_RECOVERED.md を書いてください：システムの完全な機能を、エンドユーザーに向けて、画面ごと、プロセスごとに記述し、推測したものに印を付けて。 (4) 各画面を列挙し、各要素にアクセスでき、バックエンドへの効果が検証できる形で、テスト用の道具で操作できるかを言い、一つのフローのエンドツーエンドのテストを書いて実行することでそれを示してください。(5) システムをソースから今日の道具で構築し実行しようと試み、解決しない依存関係をすべて報告してください。(6) 本番のデータをテスト環境へ複製し匿名化できるか、そして一度でも復元されたバックアップが存在するかを確認してください。(7) 外部の連携をすべて列挙し、テストモードがあるか、境界で隔離できるかを言ってください。各前提条件について：緑か赤か、証拠（あなたが何をして何が起きたか）、そして赤なら、どんなプロジェクトがそれを緑にするか。決定はしないでください：シートを私に提示してください。私が決めます。私の言語で答えてください。

Decision: [go / go after these prerequisite projects: … / no-go]. Write the final sheet to docs/ELIGIBILITY.md with the date, who decided, each prerequisite with its colour and its evidence, and, for every red one, the prerequisite project as a pending item in docs/PENDING.md marked as blocking, with its own acceptance criterion: the prerequisite verified green. Include the questions you asked and my answers.

決定：[可 / 次の前段のプロジェクトの後に可：… / 不可]。最終シートを docs/ELIGIBILITY.md に書いてください。日付、誰が決めたか、各前提条件をその色と証拠とともに。そして赤のものそれぞれについて、前段のプロジェクトを docs/PENDING.md の保留項目として、ブロックすると印し、独自の受け入れ基準とともに：前提条件が緑で検証されること。あなたがした質問と私の答えを含めてください。

Before we touch anything, we are going to set the working agreement between you and me for a system that already exists and has users. Write docs/WORKING_AGREEMENT.md with the six rules of the method (my time is sacred; zero technical debt; exact scope; documentation in the same commit; never report as done what you have not verified; speak my language), each with one line explaining what it prevents, and these five rules for an inherited system: (7) Nothing is refactored that was not asked for, and no module is rewritten. (8) Code you do not understand is read before it is touched, and what you learn goes into the system map. (9) Anything strange you find (a secret in the code, a dead path, a duplicated rule, a query without an index) is logged as a pending item with its evidence, never fixed in passing. (10) Current behaviour is the specification until the owner says otherwise: a difference between what the code does and what the business says is a discrepancy for me to decide, not a bug for you to fix silently. (11) No change reaches the test environment without the characterization suite green. Add any rules you think this system needs, marked as proposals. If you need to know something about how I work in order to write this, ask me.

何にも触れる前に、既に存在してユーザーがいるシステムのための、あなたと私の共働の約束を定めます。docs/WORKING_AGREEMENT.md を書いてください。方法の六つのルール（私の時間は神聖。技術的負債ゼロ。範囲は正確に。文書は同じコミットで。検証していないことを決してやったと報告しない。私の言語で話す）を、それぞれ何を防ぐかを説明する一行とともに。そして受け継いだシステムのためのこの五つのルールを：(7) 頼まれていないものは何もリファクタリングせず、どのモジュールも書き直さない。(8) 理解していないコードは触れる前に読み、学んだことはシステムの地図に入れる。(9) 見つけた変なもの（コードの中の秘密、死んだ経路、重複したルール、インデックスのないクエリ）はすべて、証拠とともに保留項目として記録し、決してついでに直さない。(10) オーナーが別のことを言うまで、現在の挙動が仕様である：コードがすることと業務が言うことの違いは、私が決める食い違いであって、あなたが黙って直すバグではない。(11) 特性化テスト群が緑でなければ、どんな変更もテスト環境に届かない。このシステムに必要だと思うルールがあれば、提案と印して加えてください。これを書くために私の働き方について知る必要があることがあれば、聞いてください。

We are going to recover the map of this system from what exists. Read the whole repository (every branch), the database schema (read-only), the configuration of each environment, the recent logs and whatever documentation there is; if some part cannot be read from where you are, tell me and mark it as a gap; do not fill it by guessing. Then write three things. First, complete docs/INITIAL_SURVEY.md in the form the method expects (what the system does and for whom; what it does NOT do; who uses it; the technology; the environments; what an error costs), with every statement tagged by its source: [code], [database], [configuration], [documentation], [business] for what the survey already says, or [inferred]. Second, PROJECT.md, three hundred lines at most, and docs/SEMANTIC_TREE.md: the domains and, under each one, the actors, the processes (each with trigger, steps, outcome and exceptions as the code actually implements them), the entities with the attributes, states and transitions the database and the code enforce, the screens, the external integrations and the scheduled jobs; every node tagged the same way. Third, docs/DISCREPANCIES.md: everything where the code, the database, the documentation and what the business says in the survey do not agree, with the evidence on each side. Do not resolve any discrepancy and do not fix anything: list them. Create docs/STATUS.md for the living state. Reply in my language.

存在するものからこのシステムの地図を復元します。リポジトリ全体（すべてのブランチ）、データベースのスキーマ（読み取り専用）、各環境の設定、最近のログ、そしてあるだけの文書を読んでください。あなたのいる場所から読めない部分があれば、私に言って穴と印してください。推測で埋めないでください。それから三つのものを書いてください。第一に、 docs/INITIAL_SURVEY.md を方法が期待する形で完成させてください（システムは何をして誰のためか。何をしないか。誰が使うか。技術。環境。誤りが何を要するか）。各主張にはその出所の印を付けて： [コード]、[データベース]、[設定]、[文書]、調査が既に言っていることには[業務]、または [推定]。第二に、PROJECT.md、最大で三百行、そして docs/SEMANTIC_TREE.md：ドメインと、その下に、アクター、プロセス（それぞれ、コードが実際に実装している通りの引き金、手順、結果、例外とともに）、データベースとコードが課している属性、状態、遷移を持つエンティティ、画面、外部インテグレーション、定期処理。各ノードに同じ印を付けて。第三に、 docs/DISCREPANCIES.md：コード、データベース、文書、そして調査で業務が言っていることが一致しないすべてを、それぞれの側の証拠とともに。どの食い違いも解決しないでください。何も直さないでください：列挙してください。生きた状態のために docs/STATUS.md を作ってください。私の言語で答えてください。

I confirm these nodes: [list]. Correct these: [list]. The discrepancies are decided as follows: [one line each: discrepancy, my decision, today's date]. Finalize docs/INITIAL_SURVEY.md, PROJECT.md and docs/SEMANTIC_TREE.md with today's date, keeping the source tags. Write each discrepancy decision in docs/DECISIONS.md with my exact words, and open a pending item in docs/PENDING.md for every discrepancy where I decided the system must change; for the ones where I decided the current behaviour stays, write it next to the node as a confirmed rule. Add to PROJECT.md the instruction to read this file, the tree and the working agreement at the start of every session.

このノードを確認します：[一覧]。これを訂正してください：[一覧]。食い違いはこう決まります： [それぞれ一行で：食い違い、私の決定、今日の日付]。docs/INITIAL_SURVEY.md、PROJECT.md、 docs/SEMANTIC_TREE.md を今日の日付で締め、出所の印を保ってください。食い違いについての各決定を docs/DECISIONS.md に私の言葉そのままで書き、システムを変えなければならないと私が決めた食い違いごとに docs/PENDING.md に保留項目を開いてください。現在の挙動が残ると私が決めたものは、確認されたルールとしてノードの隣に書いてください。PROJECT.md に、各セッションの始めにこのファイル、ツリー、共働の約束を読む指示を加えてください。

Audit this system for integrity, security, performance, code quality and deployability, as the inventory of what must be normalized before and during its evolution. Read-only: change nothing except writing your report to docs/AUDIT_[date].md. If auditing some part requires access you lack (the database, the logs, the server), tell me and mark that part as not audited; do not pass it as fine. Go through all of the code, not a sample, and read docs/SEMANTIC_TREE.md and docs/DISCREPANCIES.md first so that you do not report what is already known. For every finding: where it is (file and line), the risk, the evidence that proves it (the command, the query, the number), its priority (P0 must be fixed now, P1 soon, P2 when possible), and one more field: whether it BLOCKS (must be fixed before any change, by my criteria: [criteria]), whether it is PAID WHEN TOUCHED (fixed together with the first change that enters its module), or whether it CAN WAIT. Grade every dimension you audited. End with every finding turned into a proposed pending item, blocking ones first. Reply in my language.

このシステムを、完全性、セキュリティ、性能、コードの品質、デプロイ可能性について監査してください。その進化の前と最中に正常化しなければならないものの棚卸しとして。読み取り専用： docs/AUDIT_[fecha].md に報告書を書く以外、何も変えないでください。どこかの部分を監査するのに手元にないアクセス（データベース、ログ、サーバー）が必要なら、私に言ってその部分を未監査と印してください。良しとして通さないでください。見本ではなくコード全体を辿り、既に分かっていることを報告しないよう、先に docs/SEMANTIC_TREE.md と docs/DISCREPANCIES.md を読んでください。各発見について：どこにあるか（ファイルと行）、リスク、それを証明する証拠（コマンド、クエリ、数字）、その優先度（P0は今すぐ直すべき、 P1は間もなく、P2はできるときに）、そしてもう一つの項目：それがブロックするか（どんな変更よりも前に直さなければならない。私の基準では：[基準]）、触れたときに払うか（そのモジュールに入る最初の変更と一緒に直す）、それとも待てるか。監査した各次元に評点を付けてください。各発見を提案された保留項目に変えて終えてください。ブロックするものを先に。私の言語で答えてください。

We are going to build the safety belt around this system before changing anything in it. Read the environments survey, docs/AUDIT_[date].md and docs/SEMANTIC_TREE.md. Evaluate whether you have what is needed (read access to the server where it runs and to its database, write access to where the test environment will run, the way it is deployed today); if anything is missing, ask me before starting. Then set up, without touching any functionality: (1) a test environment that runs the system exactly as production does, with a copy of the data where the personal fields I listed are anonymized; (2) a reproducible deployment to that environment, run twice, showing me that the second run changed nothing; (3) every secret found in the repository or in the code moved to the server configuration (environment file or vault), with the list of what you moved so that I rotate each one; (4) continuous integration running whatever test suite exists today, even if it is a single smoke test, on every push; (5) docs/GATES.md with the gates of this project, including: nothing reaches the test environment without the characterization suite green, and nothing reaches production without the full suite green with the exact version. Document all of it in docs/DEPLOYMENT.md so that a person can do it by hand without you. Take a screenshot of the system running in the test environment and show it to me. Reply in my language.

このシステムに何かを変える前に、その周りに安全ベルトを築きます。環境の調査、 docs/AUDIT_[fecha].md、docs/SEMANTIC_TREE.md を読んでください。必要なものが手元にあるか評価してください（動いているサーバーとそのデータベースへの読み取りアクセス、テスト環境が動く場所への書き込みアクセス、今日どうデプロイされているか）。足りないものがあれば、始める前に私に求めてください。その後、どの機能にも触れずに、次を整えてください：(1) 本番とまったく同じようにシステムを走らせるテスト環境。私が列挙した個人項目が匿名化されたデータのコピー付きで。(2) その環境への再現可能なデプロイ。二度実行し、二度目が何も変えなかったことを私に示して。(3) リポジトリまたはコードの中で見つかったすべての秘密をサーバーの設定（環境ファイルまたは金庫）へ移し、私がそれぞれをローテーションできるよう移したものの一覧を付けて。(4) 今日存在するテスト群を、たとえ単一の煙テストでも、プッシュのたびに走らせる継続的インテグレーション。(5) このプロジェクトのゲートを記した docs/GATES.md。次を含めてください：特性化テスト群が緑でなければ何もテスト環境に届かない。完全なテスト群が正確なバージョンで緑でなければ何も本番に届かない。そのすべてを docs/DEPLOYMENT.md に、人があなたなしで手で行えるように文書化してください。テスト環境で動いているシステムのスクリーンショットを撮って私に見せてください。私の言語で答えてください。

We are going to write the characterization tests of these critical flows: [list]. A characterization test captures what the system does today, exactly as it does it, defects included; it is not a test of what the system should do. For each flow: drive it from the screen as a user would and check the effect in the backend (the row, the state, the message queued). Every test must pass against the current code. Then prove that each test actually watches its flow: break the flow deliberately with a temporary change, show me the red output, revert the change, show me the green. If a flow cannot be driven from the screen, do not simulate it: say so and open a pending item marked as blocking. If while writing these tests you find behaviour that looks wrong, do not fix it: add it to docs/DISCREPANCIES.md with the evidence. Record the command to run the suite in docs/STATUS.md, and make the suite the gate for the test environment as docs/GATES.md says. Reply in my language.

この重要なフローの特性化テストを書きます：[一覧]。特性化テストは、システムが今日していることを、している通りそのままに、欠陥も含めて捉えます。システムがすべきことのテストではありません。各フローについて：ユーザーがするように画面から操作し、バックエンドでの効果（行、状態、キューに入ったメッセージ）を確認してください。すべてのテストが現在のコードに対して通らなければなりません。その後、各テストが本当に自分のフローを見張っていることを証明してください：一時的な変更でわざとフローを壊し、赤の出力を私に見せ、変更を戻し、緑を私に見せてください。画面から操作できないフローがあれば、模擬しないでください：そう言って、ブロックすると印した保留項目を開いてください。これらのテストを書いているあいだに誤っていそうな挙動を見つけても、直さないでください：証拠とともに docs/DISCREPANCIES.md に加えてください。テスト群を走らせるコマンドを docs/STATUS.md に記録し、docs/GATES.md が言う通り、テスト群をテスト環境のゲートにしてください。私の言語で答えてください。

Go through the code, the database triggers and the scheduled jobs of the server looking for everything that charges, sends, approves, deletes, notifies outwards or runs on a schedule, and write docs/CONSEQUENTIAL_ACTIONS_SURVEY.md with every statement tagged by its source. Compare it with the list the business wrote in docs/INITIAL_SURVEY.md: whatever the code does that the business did not list, or the other way round, ask me about before going on. For every action: what triggers it, whether it can run twice, whether it is reversible, what lock exists today if any, and what the way back is. In the same pass, build docs/PRODUCER_CONSUMER_MAP.md: for every contract in the system (a service, a table, a file format, a list of values), who produces it and who consumes it, including the things outside the repository I told you about. If there are parts you cannot see, say so instead of leaving them out. Present me the actions table with a proposed lock for each (explicit confirmation, double safety, dry-run mode, daily limit, a human in the loop) and a proposal of which locks go NOW, before any change, and which can go when the module is touched. Do not implement anything yet: I confirm lock by lock. Reply in my language.

コード、データベースのトリガ、サーバーの定期処理を辿り、請求するもの、送るもの、承認するもの、削除するもの、外へ知らせるもの、時刻を決めて走るものをすべて探し、各主張にその出所の印を付けて docs/CONSEQUENTIAL_ACTIONS_SURVEY.md を書いてください。それを業務が docs/INITIAL_SURVEY.md に書いた一覧と比べてください：コードがしていて業務が列挙しなかったもの、またはその逆は、先へ進む前に私に聞いてください。各行動について：何がそれを発火させるか、二度走りうるか、取り消せるか、今日あれば何の錠があるか、そして戻り道は何か。同じ一周で docs/PRODUCER_CONSUMER_MAP.md を構築してください：システムのすべての契約（サービス、テーブル、ファイル形式、値の一覧）について、誰がそれを生産し誰が消費するか。私が話したリポジトリの外のものも含めて。見えない部分があれば、外に置くのではなくそう言ってください。各行動に提案された錠（明示的な確認、二重の安全、ドライランモード、一日の上限、回路内の人間）を付けた行動の表と、どの錠がどんな変更よりも前に今すぐ行き、どれがモジュールに触れるときに行けるかの提案を、私に提示してください。まだ何も実装しないでください：私が錠を一つずつ確認します。私の言語で答えてください。

Before changing anything we are going to size this system with its real numbers. With read-only access to the production database (or the complete test copy) and to the logs, measure instead of asking: rows per table and growth per month from the timestamps, events per entity, peak concurrency from the access logs, data size today and projected at five years, and the slowest queries. Write a meter for each number (a script that lives in the repository, with a test against a known case I will give you) and show me every number together with the command that produces it; audit each meter in both directions (is everything that should be counted, counted? does everything counted exist?). Write docs/VOLUME_SURVEY.md with every figure tagged [database] or [log], and ask me only for what cannot be measured: the growth the business expects and whether the system will serve more than one site. Then write docs/SIZING.md: what breaks first if everything is multiplied by ten, which of the current architecture choices hold and which do not, and which asymmetric decisions we take now, before evolving, because they are cheap today and expensive later. Do not change any code. Reply in my language.

何かを変える前に、このシステムをその実数でサイジングします。本番データベース（または完全なテストのコピー）とログへの読み取り専用アクセスで、聞く代わりに計測してください：テーブルごとの行数と日時からの月あたりの増加、エンティティごとのイベント数、アクセスログからのピーク時の並行性、今日のデータの大きさと五年後の見込み、そして最も遅いクエリ。数字ごとに計器（リポジトリに住むスクリプトで、私が与える既知の事例に対するテスト付き）を書き、各数字をそれを生むコマンドとともに私に見せてください。各計器を二つの方向で監査してください（数えられるべきものはすべて数えられているか？ 数えられたものはすべて存在するか？）。各値に [データベース]または[ログ]の印を付けた docs/VOLUME_SURVEY.md を書き、計測できないものだけを私に求めてください：業務が見込む成長と、システムが一か所より多くに仕えるかどうか。その後 docs/SIZING.md を書いてください：すべてが十倍になったら何が最初に壊れるか、現在のアーキテクチャの決定のどれが耐えてどれが耐えないか、そして今日は安く後では高いから、進化する前に今どんな非対称な決定を取るか。コードは何も変えないでください。私の言語で答えてください。

We are going to turn the normalization and the client's request for this stage into one queue of numbered pending items in docs/PENDING.md, each with its full specification as the method asks (number, title, node of the semantic tree, origin, description, business rules with decision and date or marked as missing, data in and out, screens, edge cases, acceptance criteria as given, when, then, how it will be verified, status). Sources for the normalization items: docs/AUDIT_[date].md, the discrepancies I decided to change, the screens that cannot be driven by a program, the secrets to rotate, the locks that are not implemented yet, and the decisions in docs/SIZING.md; each one keeps its speed mark: BLOCKS, PAID WHEN TOUCHED, or CAN WAIT. Sources for the client's items: the client's request for this stage; each one marked CORRECTIVE (something that fails today, with the way to reproduce it in the client's words) or EVOLUTIVE (something new). For every client item, list the normalization items that touch the same modules and should be paid together with it. If the request is ambiguous on any point such that you cannot write a verifiable item, ask me; do not resolve it by assuming. Order: blocking items first, then the client's items in the priority I gave you, each with its paired normalization. Reply in my language.

正常化とこの段階に対する顧客の依頼を、docs/PENDING.md の中の番号付き保留項目の一つのキューに変えます。それぞれ方法が求める完全な仕様付きで（番号、題名、セマンティックツリーのノード、出所、記述、決定と日付を伴う業務ルールまたは欠落と印したもの、入るデータと出るデータ、画面、境界ケース、「ある状況を前提に、あることが起きたとき、ならば」の形の受け入れ基準、どう検証するか、状態）。正常化の項目の出所：docs/AUDIT_[fecha].md、変えると私が決めた食い違い、プログラムから操作できない画面、ローテーションすべき秘密、まだ実装されていない錠、そして docs/SIZING.md の決定。それぞれが速度の印を保ちます：ブロックする、触れたときに払う、または待てる。顧客の項目の出所：この段階に対する顧客の依頼。それぞれに修正（今日失敗していること、顧客の言葉による再現の仕方とともに）または進化（新しいこと）と印してください。顧客の各項目について、同じモジュールに触れていて一緒に払うべき正常化の項目を列挙してください。依頼がどこかの点で曖昧で検証可能な項目を書けないなら、私に聞いてください。推測で解決しないでください。順序：ブロックする項目を先に、その後に顧客の項目を私が与えた優先順位で、それぞれ対になった正常化とともに。私の言語で答えてください。

This pending item is a correction: [what fails, in the client's words, and how to reproduce it]. Before changing anything: (1) Reproduce the failure with a test that drives the flow from the screen and checks the effect in the backend, and show me that it fails against the current code; that red is the proof that you reproduced the right defect. If you cannot reproduce it, tell me what you tried and what you need; do not fix what you cannot see. (2) Find the root cause and tell me in prose, with the evidence, before fixing. If the root cause is a business rule nobody wrote down, stop and ask me. (3) Fix at the root, not where it hurts, and nothing else: anything else you find goes to a pending item. (4) Show me the test green, the characterization suite still green, and the regression of the neighbouring items. (5) If the fix changes a current behaviour that someone may depend on, say so explicitly: that is a decision for me, not a side effect. Close the paired normalization items of this module in the same block, each with its own evidence. The commit message says "proved red against [version]" and the test counts. Reply in my language.

この保留項目は修正です：[何が失敗するか、顧客の言葉で、そしてどう再現するか]。何かを変える前に：(1) 画面からフローを操作してバックエンドでの効果を確認するテストで失敗を再現し、現在のコードに対して失敗することを私に見せてください。その赤が、正しい欠陥を再現したことの証明です。再現できないなら、何を試して何が必要かを私に言ってください。見えないものを直さないでください。(2) 根本原因を見つけ、直す前に、証拠とともに散文で私に言ってください。根本原因が誰も書かなかった業務ルールなら、止まって私に聞いてください。(3) 痛むところではなく根で直し、それ以外は何も：ほかに見つけたものは保留項目へ行きます。(4) テストが緑であること、特性化テスト群がまだ緑であること、そして近隣の項目の回帰を私に見せてください。(5) 修正が、誰かが依存しているかもしれない現在の挙動を変えるなら、はっきりそう言ってください：それは副作用ではなく私の決定です。このモジュールの対になった正常化の保留項目を同じブロックで、それぞれ自分の証拠とともに閉じてください。コミットのメッセージには「[バージョン]に対して赤で証明」とテストの数を書いてください。私の言語で答えてください。

This is an urgent fix on production: [what is happening]. Do the minimum that stops the damage, on a branch, with the rollback ready before you deploy, and tell me exactly what you changed and what you did not verify. Do not touch anything else. Then, today, open the corrective pending item in docs/PENDING.md with what happened, and we close it with the full routine: the test that reproduces it in red, the root cause, the fix at the root, the characterization suite and the regression green. Reply in my language.

これは本番での緊急の修正です：[何が起きているか]。損害を止める最小限を、ブランチの上で、デプロイする前にロールバックを用意した上で行い、正確に何を変えて何を検証しなかったかを私に言ってください。ほかには何にも触れないでください。その後、今日のうちに、docs/PENDING.md に何が起きたかを記した修正の保留項目を開いてください。それを完全なルーチンで閉じます：それを再現する赤のテスト、根本原因、根での修正、特性化テスト群と回帰が緑であること。私の言語で答えてください。