breakthrough-performance-db-setup

Breakthrough Performance DB のセットアップ

1つのシステムを、1人の学生のために、1回だけインストールします。目指す状態は明確で確認可能です。その学生自身の広告費が毎日その学生自身の Base のコピーに反映され、そこに表示される数値が Ads Manager と一致し、保管庫には、来週のセッションでそれぞれの場所が分かるように記したノートが保存されています。

以下のすべてを左右する一文です。このインストールの各ステップは、成功したように見えながら失敗する可能性があります。だから、仕事はステップを完了させることではなく、それぞれが実際に行われた証拠を残すことです。 ワークフローが無効になっている Base のコピーも、動作するものと見分けがつきません。500行のうち25行だけを取得した同期も、普通のデータに見えます。平均注文額を入力したマージンフィールドは、あらゆる判定で常に同じ方向に誤った損益分岐ラインを作り、エラーも出しません。ゲート4、6、8とランタイムチェックがあるのはそのためです。

プロダクト内での位置付け

このスキルは my-second-brain で構築された保管庫内で実行されるものであり、同梱されているわけではありません。 別途インストールおよび更新され、保管庫に書き込む内容はすべて、このファイルではなく、そこにある保管庫のルールに従います。

保管庫に書き込む内容を規定するのは、その学生自身の 99_Meta/structure-doctrine.md です。書き込む時点で必ず最新の内容を読みます。 ⛔ このパッケージにはそのコピーは含まれていません。セクション8では書き込むノートの形式を、セクション0では保管先の判断ツリーを、セクション5では名前の規則を定めています。⛔ セクション8の記憶に頼ることは決してせず、⛔ ここから引用したキーの一覧も決して使わないでください。この学生が自身の規約を変更している可能性があります。

⭐ この非対称性は重要なので、上記のルールを過剰に適用しないでください。 保管庫には最新のルールの参照元があり、あなたはそれを読みます。Lark と Meta にはありません。 コピーした Base の動作、+field-update がひそかに破棄するもの、Meta トークンで典型的に起きる失敗を記録したファイルは、学生の環境には存在しません。そのため、このパッケージの references/ ファイルにはそれらの知識がすべて含まれており、そこが情報源です。保管庫のルールは最新の内容を読み、このパッケージの仕組みについてはこのパッケージを参照してください。

⛔ このスキルは何も約束しません。 「1回のセッションでインストール完了」といった説明も、所要時間の見積もりも、最後に学生が何を得られるかという主張もありません。広告アカウントを所有する代理店が原因でゲート1で進めなくなる学生もいます。その場合、このインストールで解決する方法はありません。現在のゲートで必要なことと、その合格条件を伝えてください。⛔ 実現する前に、所要時間や結果を学生の言葉として伝えてはいけません。

学生自身が使う言語で話してください。 このファイルは英語ですが、セッションで使う言語はそうとは限りません。コードスイッチングも含め、相手が使う言葉に合わせ、フィールド名と判定語はボードに表示されているとおりにしてください。

ゲート 0：ツールチェーン。ここは必須のゲートです

ゲート 2 以降のすべてのゲートでは、学生本人の ID を使い、lark-cli 経由で学生の Base にアクセスします。 ゲート 2 ではテンプレートをコピーし、そのコピーから名簿を読み取ります。ゲート 4 では Targets に書き込み、行を読み戻します。ゲート 5 では 6 つのテーブルを消去して件数を数えます。ゲート 7 では同期ワークフローを編集します。ゲート 8 ではボード独自の集計を経由せずに、生データの行を再集計します。⭐ つまり、これはゲート 2 のための付属物ではありません。残りのインストールを支える土台です。 ゲート 4 でこれがないと判明するセッションでは、ゲート 1 から 3 までで学生の夜の時間をすでに使ってしまっています。

確認するのは 3 項目で、質問ではなくチェックです。 ゲート 1 の Vault プローブと同じ姿勢で、正常に動作するかどうかを調べます。⛔ インストールされているかどうかについて学生の意見を聞くのではありません。

1. lark-cli --version がバージョンを返します。
2. lark-cli whoami が、トークンの状態が needs_refresh ではない ユーザー ID を返します。⚠️ ユーザートークンはひっそりと期限切れになります（lark-lessons.md:76）。期限切れになると、かなり後になって認証オブジェクトの解析エラーとして表面化し、ログイン切れではなくスクリプトの不具合のように見えます。
3. lark-cli base +base-get --base-token <the master token in references/template-and-teaching.md> がテンプレートの情報を返します。⭐ この 1 回の呼び出しで、4 つのことを同時に確認できます。 CLI がインストールされていること、ログインが有効であること、スコープが Base にアクセスできること、そして この学生が実際にテンプレートを閲覧できることです。ゲート 6 で 1 回の Insights 呼び出しにより、アプリ、Marketing API 製品、System User、ads_read をまとめて確認するのと同じ形です。

チェックに失敗した場合、修正コマンドは学生自身が実行します。ブラウザーを使う手順では、2 回の往復が必要です。

• チェック 1 で何も見つからなかった場合は、npm install -g @larksuite/cli を実行します。⚠️ npm のプレフィックスがシェルの PATH に含まれていないマシンでは、インストールが成功してもバイナリが見つからないままになることがあります。インストールに失敗したと判断する前に、フルパスで解決してください。
• lark-cli config init --new は、ブラウザー経由で Lark アプリを作成して紐付けます。⛔ 開発者コンソールでアプリを手動作成する必要はありません。⛔ そこへ誘導してはいけません。
• lark-cli auth login --domain base,drive でスコープを許可します。Base をコピーすると学生の Drive にファイルが作成されるため、base とともに drive も必要です。
• ⭐ 手順を案内してください。代わりに実行しようとしてはいけません。 どちらのコマンドも、学生本人にしか完了できないブラウザー操作で停止します。最初のコマンドをバックグラウンドで実行し、出力から確認用 URL を取り出して、表示されたとおりの URL をそのまま渡してください。⛔ URL を再入力、再エンコード、再構成してはいけません。

⛔ このゲートでも、後続のどのゲートでも、近道としてオーナーの認証情報を提示してはいけません。 それらはオーナーのテナント全体へのアクセスを許可します。また、ユーザートークンは OS のキーチェーンに保存されるため、いずれにせよマシン間で移動できません（lark-lessons.md:70）。さらに、その認証情報を使ってコピーすると、学生の Drive ではなくオーナーの Drive に保存されます。

⚠️ このゲートでは解決できない失敗が 1 つあります。学生によるアプリ作成を許可しないテナントです。これについては、堂々巡りを続けるより、はっきり伝えるほうがよいでしょう。 個人用 Lark テナントでは学生自身が管理者なので、学生が手続きできますが、会社のテナントでは拒否されることがあります。その理由で config init --new を完了できない場合は、何がブロックされているか、組織内の誰が解除できるかを伝えて、そこで止めてください。⛔ 回避策はありません。場当たり的な方法を試すより、正直にそこで止めるほうがよいでしょう。

合格条件： チェック 3 で、学生本人の ID を使ってテンプレートの情報が返されたこと。⛔ 「インストールしたと言っている」では不十分です。

ゲート 1：適格性の完全な確認

ここは 「いいえ。回避策もありません」 で終わる可能性が最も高いゲートです。そのため前のほうに置かれており、参考資料ではなくここに詳しく記載しています。⛔ これだけではありません。ゲート 0 ではアプリ作成を許可しないテナント、ゲート 6 ではアクセスを拒否する Meta が原因で終了することがあります。このパッケージは、どのゲートにも解決策を約束しません。ゲート 1 に失敗する人にゲート 2 から 7 まで実行すると、本人とあなたの夜の時間を無駄にしてしまいます。 アクセスに関する3つの確認事項。 直接尋ね、回答は後で確認する主張として受け止め、事実として扱わないでください。

1. 本人が自分のMeta Business Managerを所有していること。 ⛔ 代理店が所有するアカウントは対象外です。学生は同期に必要なSystem Userを作成できず、「代理店に聞いてみます」と何度言っても、このセッション中に解決することはありません。
2. 広告アカウントの管理者であること。 広告主やアナリストではありません。
3. Baseを作成できるLarkアカウントを持っていること。 ⭐ ゲート0ですでに実際に確認済みなので、再度尋ねず、確定事項として扱ってください。

⭐ 確認事項1と2は不可欠ですが、自己申告による確認で問題ありません。 学生の認識が誤っていれば、ゲート6でSystem Userの作成とInsightsの呼び出しを試した際に、実際に成功するかどうかで明らかになるからです。ゲート1は、すでに答えが「いいえ」だとわかっている人の時間を無駄にしないためにあります。

4つ目は質問ではなく、確認事項です。ボールトを調べてください。 99_Meta/structure-doctrine.mdを探します。

• ⭐ 探すのはファイルです。 相手のボールトがどこにあるかわからない場合に限り、「ボールトはどこにありますか？」と尋ねてから調べてもかまいません。⛔ 「セカンドブレイン用のボールトはありますか？」と尋ねてはいけません。その質問で得られるのは本人の見解ですが、必要なのは、存在するかしないかがはっきりしているファイルです。
• ⛔ ファイルがなければ、インストールを中止してください。 このシステムでは、来週の分析でデータベースを再度尋ねずに見つけられるよう、メモを残すこと、そのメモはこのボールトにはまだないルールに従って保存する必要があること、ボールトのインストールは別の作業（my-second-brain）であり、本人が実行する必要があることを、はっきり伝えてください。不足しているものと、誰が対処するのかを伝え、そこで中止します。
• ⛔ 代わりに普通のメモを書いて済ませてはいけません。 ボールトが認識できない形式のメモは、メモがないよりも悪い状態です。ボールト自身のメンテナンス処理では見つけられず、フロントマターの検証機能に拒否または警告され、学生は実際には持っていない情報への参照があると思い込んでしまいます。

5つ目は質問ですが、見落とされがちな質問です。「リードを特定の広告にどう紐づけていますか？」 「リードを追跡していますか？」ではなく、今日入ってきたリードが、それを獲得した広告にどう結び付けられるのかを尋ねてください。広告ごとに異なるWhatsAppのクリックしてチャットするリンク、フォームのフィールド、ランディングページのパラメーター、専用の電話番号など、実際の仕組みを説明してもらいます。

⛔ 何かをコピーする前に、ゲート1で対象外となる範囲を伝えてください。 要点を口頭で、次のように伝えます。

このシステム全体は、1つのテキストキー<ad-id>__<YYYY-MM-DD>で動いています。すべてのローリングウィンドウ、すべての適格リードあたりのコスト、すべての判定は、このキーで検索します。来店客には広告IDを付けられません。共有電話番号への通話にも広告IDを付けられません。 リードの大半がその経路で入ってくる場合、このボードの広告側は正しくても、リード側は空のままです。移行しても、数式を使っても、後から修正しても、リードが到着した時点で取得されなかったキーを作り出すことはできません。

⭐ ゲート1でこれを伝えてください。伝えないと、学生は教材に問題があると思い込みます。 「自分のアトリビューションには合わない」ではなく、自分のデータを入れて構築してから3週間後に、「このシステムは動かない」と結論付けるでしょう。

ファネルが合わない場合は、はっきり伝えてください。 ⛔ 合っているふりをしてはいけません。また、⛔ 数字がよく見えるよう、「会話」の定義を黙って広げてはいけません。このセッションで既存の設計を一緒に確認し、リード側を独自に変更した形で構築してもらうことはできます。これは正当な対応であり、多くの場合、適切な方法です。⭐ そうする場合は、実際に構築した内容を必ず学生のボールトのメモに記録してください。 来週の分析ではそのメモを読み、別途記載がない限り標準の構成だと想定するためです。手順はreferences/vault-note.mdに記載されています。

ゲート2から10：統制要件

2. テンプレートをコピーし、そのコピーを実行します。 ⭐ lark-cli base +base-copy を使えば、学生が手作業で行う作業を1回の呼び出しで実行できます。ゲート0で確認した本人の認証情報を使い、コピーは本人が所有する状態で本人の Drive に保存されます。⛔ これは「プロビジョナーではなくテンプレートを使う」というルールで禁止されているものではありません。 そのルールが対象にしているのは、Base の各フィールドを一つずつ作成することです。数百回の呼び出しが必要で、その一つひとつが失敗の原因になります。コピーなら1回の呼び出しで済みます。⛔ コピーは学生本人の認証情報で実行し、所有者の認証情報は決して使いません。新しい Base は、そのトークンを使って作成した人のものになり、API にそれ以外を指定するパラメーターはないためです。次に、テーブルはすべて名前で解決し、実行時に本人のコピーから名簿を読み取ってください。コピー時に table_id が再生成されるため（lark-lessons.md:706）、ID をどこかに書き留めると、2人目の学生で問題が発生します。⛔ コピーには明示的にタイムゾーンを指定してください。 呼び出しではタイムゾーンが引き継がれません。また、指定せずに作成したコピーのタイマーは、テンプレートで見える時刻とは異なる時刻になり、各学生の07:00が知らないうちに別の時刻になってしまいます。フラグと正確な指定形式は、references/template-and-teaching.md のコマンドと併せて記載されています。⛔ テスト項目1に合格してください。コピーのトークンはマスタートークンではありません（references/changing-the-base.md §0）。⭐ コピーを自分で実行すると、この確認は不要になるどころか、より確実になります。トークンは学生のクリップボードからではなく、API の戻り値として受け取れるからです。マスターは正常なオリジナルなので、リストにある他の確認項目はすべて満たします。両者を見分けられるのはトークンだけです。続いて、8つのテーブルすべてを名前で解決し、同期ワークフローが無効になっていることを確認します（コピーにはワークフローも含まれますが、無効のままです。lark-lessons.md:702）。⛔ 手動での手順は削除しません。 ゲート0の合格後に呼び出しが失敗した場合は、リンクを渡してクリックしてもらい、同じ合格確認に戻ってください。コマンド、その条件、新たに加わる唯一の失敗要因については、references/template-and-teaching.md に記載されています。

3. デモボードについて説明します。 ⛔ 教える場であり、試験ではありません。 「これが何を意味するか分かりますか」と尋ねて、その答え次第でインストールを許可するかどうかを決めてはいけません。⭐ 2つの例を見せて、そこで終わりにします。ボード上で会話あたりの広告費が最も安い広告は KILL、最も高い広告は SCALE です。この比較こそが、このシステム全体が存在する理由です。⛔ ほかの判定について一つずつ説明しないでください。学生自身の広告に紐づいて、毎週自動的に表示されます。ここに合格確認がないのは意図的です。翌週には、学生自身のお金がかかったボードを使って同じ説明をもう一度聞くことになり、そのときに本当に理解できます。

4. Targets に入力します。 ⭐ 学生に数値を言ってもらい、あなたが入力します（references/changing-the-base.md に記載のとおり、トークンを確認してから行を読み返します）。⛔ 学生自身に入力させないでください。このゲートで防ぐべき誤りは、注文額を利益率のフィールドに入力してしまうことです。あなたがキーボードを持っていれば、その誤りは起こりません。回答から損益分岐点を計算し、入力する前に本人の同意を得てください。数値の通貨単位を尋ねて記録してください。ゲート6には、それ以外に通貨を確認する方法がありません。⭐ ここで数値を一つ間違えると、今後のすべての判定が同じ方向に狂います。ROAS の合格基準は損益分岐点であり、損益分岐点は利益率から算出されるためです。参考資料にある、厳守すべき確認事項は2つです。粗利益率が平均注文額以上なら、その時点で誤りです。また、損益分岐点 ROAS が1.0付近になるのは、注文額を利益率のフィールドに入力した際の典型的な兆候です。 合格条件：本人が、自分の入力値から算出された損益分岐点を確認し、その数値に同意していること。 5. デモデータをクリアします。 6つのテーブルを空にし、TargetsとAccountにはそれぞれ1行を残します。⛔ これを忘れると、デモの行が実データに混ざり、ボード上のすべての数値が気づかれないまま誤ったものになります。これはBaseへの変更なので、references/changing-the-base.mdに従って実行し、行を再度一覧表示して自分で件数を数え、検証します。⭐ ここで空にした広告レイヤーは、手作業ではなく最初の同期で再び埋まります。その合格テストはゲート7で行い、どちらもreferences/template-and-teaching.mdに記載されています。

6. Metaのトークンを取得します。 ⛔ クリック手順をハードコードしないでください。 MetaのUIは絶えず名称や配置が変わるため、古いメニュー名だらけのスキルでは、教材が古いと学生に思わせてしまいます。実行時に最新の手順を見つけて、学生を案内してください。⭐ 手順ではなく、最終状態を検証します。Insightsの呼び出しが1回成功すれば、アプリ、Marketing API製品、System User、割り当て、ads_readを一度にすべて確認でき、どのような再設計にも影響されません。⚠️ ただし、呼び出しの成功はトークンの出所を証明しません。 短期ユーザートークンでも通過してしまいます。これはこのゲートで最もよくある失敗で、同期が停止して数週間後に発覚します。そのため、有効期限と出所も確認し、失敗した場合は、単に動かなかったと言うのではなく、4つの要素のうちどれが不足しているのかを明示してください。手順と、この最初の実データ呼び出しに伴う3つの実行時チェックは、references/meta-token-and-sync.mdに記載されています。

7. 同期を設定します。 すべてのプレースホルダーを置き換え、ワークフローを有効にし、手動で1回実行した後、実際に行が存在することを確認します。⛔ プレースホルダーの数をこのゲートに持ち込まないでください。ワークフローを読んでHTTPステップの数を確認し、各ステップを読んでそのステップ固有の数を確認してください。配線していないステップは何も通知せずに失敗し、そのステップのテーブルだけが更新されなくなります。合格テストには3つの項目があり、行の確認は最初の1つにすぎません。 Ad Dailyに行があること。緑色の実行結果ではありません。ゲート5でクリアした行数から想定される行数まで、広告レイヤーが再び埋まっていること。そして、Account.sync-last-runを読み戻し、今回の実行時刻が保持されていることです。このゲートでは最後にタイムスタンプを記録するため、記録に失敗すると、実行が完全に正常だったように見え、次回のトリガーで重複が発生します。⛔ 「ワークフローが実行された」を「データが届いた」と解釈してはいけません。また、「データが届いた」を「ゲートを通過した」と解釈してはいけません。

8. 照合します。これは依頼ではなくゲートです。 ⛔ 「一致していますか？」への「はい」という回答は証拠になりません。 その比較が行われるところをあなた自身は確認しておらず、このシステムで起こりうるすべての失敗（キーに余分なスペースが入る、数式が誤ったオブジェクトに結びついている、ロールアップが気づかれないままゼロを返す）は、エラーではなく、もっともらしい数値を返します。⭐ 証拠があなたに届くようにします。日付範囲はあなたが指定し、学生がAds Managerの数値を報告し、トークンが同じ範囲のInsightsを独立して取得します。そして、Base独自のロールアップは検証対象の1つなので、それを介さず、Ad Dailyの生データの行をあなた自身で再集計します。 3者間の差分を確認します。詳細はreferences/reconciliation-and-handover.mdに記載されています。

9. vaultのノートを書きます。 事業部門の01_Assets/IT-Systems/にit-systemノートを1つ作成し、Baseへの参照と、来週のセッションで改めて確認せずに済む情報をすべて記載します。事業部門が1つに特定できれば、そのまま進めます。2つ以上ある場合は、どの事業がこの広告アカウントを所有しているかを一度だけ尋ねます。⛔ Metaのトークンは決して記載しません。 frontmatter、書き込み前に読み取るルール、記録ログの行を含む全仕様は、references/vault-note.mdに記載されています。 10. 引き継ぎ。 簡潔にし、機能紹介ではなく読む順序にしてください。まず同期が最新かを確認し、次にチームがさらにリードを受け入れられるかを確認し、それから最終判断を示します。⛔ SCALEを先に読んで行動する学生は、誰も対応していないファネルに資金を注ぎ込むことになります。ここに記載する注意点は、ほかの場所には記載しない次の2つです。Metaトークンはワークフロー内にあり、そのBaseの編集権限を持つ人なら誰でも読めること、そしてゲート6の実行時チェックで確認したタイムゾーンと通貨に関する事実です。references/reconciliation-and-handover.md を参照してください。

このスキルの残りの部分を読み込む

タイミング	読むもの
ゲート2～5、Lark側	references/template-and-teaching.md
ゲート6と7、Meta側	references/meta-token-and-sync.md
ゲート8と10	references/reconciliation-and-handover.md
ゲート9、vaultに入るものすべて	references/vault-note.md
どのゲートでも、学生のBaseを変更する場合	references/changing-the-base.md

⛔ 必要なゲートで、その都度読み込んでください。 セッション開始前に5つすべてを読むと、最初のゲートを実行するために、インストール全体の内容でコンテキストを使い果たしてしまいます。

絶対に守ること

• ⛔ Metaトークンは、どのような場合でもvaultに入れてはいけません。 ノートにも、例にも、引用したエラーメッセージにも入れてはいけません。このスキルが扱う場所では、ワークフローのプレースホルダーにのみ置きます。
• ⛔ 学生のBaseへの変更はすべて、§1aを含め、references/changing-the-base.md に従います。 このファイルでは3種類の変更を区別しており、4つの条件が適用されるのはそのうち1つだけです。ゲート7のプレースホルダーへの入力はインストール時の設定です。すでに稼働しているBaseへの移行には4つすべてが必要です（このパッケージで宣言され、パッケージとともにバージョン管理され、vaultノートに記録され、適用済みかどうかを検出できること）。学生が所有するバリアントには最初の2つの条件は適用されず、代わりに書面での記録と、形状が不明なものとして恒久的に扱うことが求められます。⛔ 3種類すべてに4つの条件を適用してはいけません。そうすると、インストールも、このスキルが明示的に支援を許可しているバリアントの作成も禁止してしまいます。判断基準は、次のセッションが、このスキルとそのノートだけを手元に、現在のBaseがどのような状態か説明できるかどうかです。説明できないなら、それは場当たり的な対応であり、場当たり的な対応が学生のコピーを診断不能にします。
• ⛔ vaultのパスがすでに存在する可能性がある場合は、書き込む前に必ず読み込んでください。 frontmatterガードが監視するのは新規作成だけです。fm-guard-hook.sh:346 は既存のパスをそのまま通します。コメントには "an edit, not a birth; this guard watches births" とあり、fm-guard-hook.sh:369 では Edit がそもそもマッチャーではないことが示されています。そのため、2回目のインストール実行でノートを確認せずに書き込むと、止めるものが何もないまま、ファイル全体が無言で置き換えられます。
• ⛔ vaultノートの作成には必ずWriteツールを使い、Bashは使わないでください。 ガードはWriteの内容を読み込み、その中のfrontmatterを確認できますが、heredocの内容は読み取れず、正規表現で>>もブロックされます。シェル経由でノートを書くと、ノートの形式を検出できた唯一のチェックを回避することになります。
• ⛔ 終了コードは証拠にならず、ok: trueも証拠にはなりません。 書き込んだ内容を読み返し、消去したものを数え、意図した内容と照合してください。

インストール時に判断が必要なこと

このテンプレートについて、知らないとそれぞれに半日を費やすことになる事実が3つあります。

• NOW() は数式内で固定されますが、TODAY() は固定されません（このテンプレートそのものを基準に測定、lark-lessons.md:180-181）。⭐ そのため、このボードのすべてのローリングウィンドウはライブ数式であり、同期処理は何も計算しません。生の行を書き込み、計算はボードが行います。⛔ したがって、古くなったウィンドウを数値で「修正」してはいけません。ウィンドウは古くなっていませんし、そこに入力した値は、いつまでも期限切れにならない嘘です。
• リンク先のテーブルと同じ名前のリンクフィールドは、エラーにならずにテーブル全体を参照します（lark-lessons.md:95）。すべての行の値を1つの文字列に結合して返し、エラーにはなりません。そして、すべての行に同じ値が表示されます。そのため、スキーマの問題ではなく、データの問題のように見えます。ここでフィールドを作成または名前変更する場合は、⛔ テーブル名と同じ名前を付けてはいけません。
• テーブルをまたぐロールアップは、エラーにならず、下方で失敗します。 同期処理で書き込まれた行はリンクフィールドに自動で紐付かないため、リンクをまたいで書き込まれたロールアップは、それらの行を黙って除外します（lark-lessons.md:680）。FILTER の結果列に数式列を使うと、エラーにはならず空の値が返されます（lark-lessons.md:222）。どちらも、もっともらしい小さな数値を返します。⭐ だからこそ、ゲート8ではボード独自の合計を信用せず、Ad Daily の生データを自ら再集計します。合計値こそが検証対象だからです。

決定済みで、再検討しないこと

すでに決まった内容を議論し直すことで、どのセッションも学生の時間を無駄にしないよう記録しています。

• ⛔ テンプレートは現状のまま提供します。 再設計、幅広いスキーマ、2つ目のテンプレート、A/C の分割、Eコマース版、モードフラグは行いません。これらはすべて検討され、撤回されました。追加の提案は、セッションの決定ではなく、プロダクトの決定です。
• ⚠️ バージョン表記もその一覧に含まれていましたが、今は含まれません。 プロダクトオーナーは2026-08-24にその決定を覆しました。この行が示しているのはその経緯であり、現在テンプレートには Account.template-version が含まれています。⛔ 使用する前に、references/changing-the-base.md §1 の3つの条項を読んでください。これらにより、バージョン表記は構造に関する決定から完全に切り離されています。⛔ この決定の撤回は、上記の一覧にあるほかの項目の前例にはなりません。
• ⛔ このスキルは、誰かの Vault のドクトリンを変更しません。 また、自分のメモを置くために type: を追加することも提案しません。それは Vault の所有者が、自身の Vault ツールを使って判断することです。
• ⛔ このスキルはテンプレートの Base 自体を編集せず、学生がコピーしたものだけを編集します。 読み取ることは問題ありません。ゲート0の3つ目のチェックでも実際に読み取ります。⛔ 書き込みを防ぐために、changing-the-base.md §0 が存在します。
• ⛔ コピーは学生の認証情報で実行されるか、実行されないかのどちらかです。 決定済みの内容として、セッションでは学生にクリックを求めるのではなく、コピーを実行します。ただし、所有者のアカウントを使って実行することはありません。どのようなラッパーを使う場合でも、所有者の認証情報を同梱する提案は、セッションの決定でもプロダクトの決定でもありません。
• ⭐ 納品物はインストールであり、Vault のメモがそれを存続させます。 正しく接続された Base があってもメモがなければ、学生には説明できないシステムになります。そして翌週のセッションでは、質問を重ねてその仕組みを再発見しなければなりません。