zephyr

Zephyr スキーム

「Zephyr」は、サワードウのパン作りに関する音声メモにタグを付けるためのセンチネルワードです。

パン作りに関連する各音声メモは、「Zephyr N」で始まります。N はパン作りを始めた月の日付です。

例：5月28日にパン作りを始めた場合、パン作りの全サイクルを通じて、すべてのメモにキー「Zephyr 28」を使用します。

センチネルワード「Zephyr」が選ばれたのは、パン作りに関する会話では珍しく、2音節で、音声的に区別しやすいためです。音声テキスト変換で日付、数字、一般的な単語と混同されることはありません。

同じ日に複数のパンを作る場合

同じ日に複数のパン作りを始める場合は、ハイフンの後に数字のサフィックスを付けて区別します。

「Zephyr 3」は、今月3日に始めた最初のパン作りを意味します。サフィックス「-1」は暗黙的に含まれており、省略できます。

「Zephyr 3-2」は、今月3日に始めた2回目のパン作りを意味します。

5月に発話された「Zephyr 5-5」は、5月5日に始めた5回目のパン作りを意味します。

サフィックスは、パン作りのログファイル名にある末尾のパン番号に直接対応します。

センチネルがない場合

センチネルはフィルターであり、必須条件ではありません。

ほとんどのテキストには Zephyr キーが含まれておらず、キーのないテキストはこのスキームの対象ではありません。

センチネルが見つからない処理は成功です。依頼された処理を正確に実行したことになります。

処理対象が見つからないことは失敗ではありません。

指示は条件付きです。テキストに Zephyr エントリがあれば処理し、なければ条件が成立しなかったというだけです。

条件が成立しないことはエラーではないため、実行を失敗として報告したり、該当するものがなかったことを理由にゼロ以外の終了コードを返したりしてはいけません。

何も言わないでください。

キーが見つからなかったことを説明したり、キーのないエントリを列挙したり、キーのないエントリは変更されないというルールを言い直したり、該当なしを発見事項、逸脱、異常として提示したりしないでください。

変更された内容だけを報告してください。

実行で何も変更されなかった場合は、何も出力しないでください。要約、確認、処理対象がなかったことを告げる行も出力しないでください。

これは、このスキームに含まれるすべての動詞スキルに適用されます。

実行されても処理対象が見つからないスキルは、通常の状態にあり、例外的な状態ではありません。

パラメーター

このスキルは、Python のキーワード引数のように、デフォルト値を持つ名前付きパラメーターを受け取ります。

解決の優先順位（高い順）：

1. 呼び出しまたはリクエストで明示された値
2. マシンローカルの設定
3. 組み込みのデフォルト値

パラメーター：

• パン作りログのディレクトリ — 組み込みのデフォルト値は /Users/mtm/Documents/Obsidian Vault/。マシンローカルでの上書きには ZEPHYR_BAKE_LOG_DIR 環境変数を使用します。呼び出し時は、リクエストでディレクトリ名を指定して上書きできます。

動詞スキルはそれぞれ追加のパラメーターを定義し、同じ優先順位で解決します。

呼び出し時に Bash で ZEPHYR_BAKE_LOG_DIR を確認してください。未設定の場合に限り、組み込みのデフォルト値にフォールバックします。

現在の作業ディレクトリをパン作りログのディレクトリと見なしてはいけません。

パン作りログの命名規則

このセクションが、パン作りログのファイル名解決を一元的に定義します。

ルーティングを含むその他すべてのコンポーネントは、ファイル名の規則を繰り返すのではなく、これらのルールを通じてファイル名を解決します。

パン作りログは、パン作りログのディレクトリ（「パラメーター」を参照）に保存されます。

命名パターン：bake log M-D-YYYY-N.md

N はその日に作ったパンの番号で、1 から始まります。

サフィックスは必ずしも -1 とは限りません。同じ日に始めた2回目のパン作りは -2、3回目は -3 となり、以降も同様です。

N は Zephyr キーのサフィックスに直接対応します。「Zephyr 3-2」はパン番号2に解決されます。

例：

• bake log 5-28-2026-1.md — 2026年5月28日に始めた最初のパン作り
• bake log 5-21-2026-1.md — 2026年5月21日に始めた最初のパン作り
• bake log 6-3-2026-2.md — 2026年6月3日に始めた2回目のパン作り

Zephyr キーをパン作りログに対応付ける

2026年5月現在の「Zephyr 28」→ bake log 5-28-2026-1.md。

2026年6月現在の「Zephyr 3-2」→ bake log 6-3-2026-2.md。

Zephyr の日付番号は、パン作りを始めた月の日付です。現在の月と年を組み合わせて、完全な日付を解決します。省略可能なサフィックスはパンの番号です。指定がない場合は1とします。

Zephyr エントリーの読み取り

bake log の各 Zephyr エントリーは、次の形式になっています。

For Zephyr N, [event description] at [time] on [date].

ヘッダーのタイムスタンプ（エントリーの上にあるタイムスタンプ見出し）は、メモが記録された時刻です。

イベントのタイムスタンプは、本文中に記載されている時刻で、実際にパン作りの作業が行われた時刻です。

パン作りのイベントを抽出するときは、必ずヘッダーのタイムスタンプではなく、イベントのタイムスタンプを使用してください。

文字起こしの誤り

エントリーは音声認識で文字起こしされているため、前後の文脈から誤りだと分かる単語が含まれることがあります。

文脈から正しい単語が確定できる場合に限り修正し、確定できない場合は、読み上げられたとおりに残してください。

根拠は同じ bake log 内になければなりません。たとえば、そのログの手順、別のエントリー、またはエントリーに記録された測定値などです。

例：「the initial dial volume is 1100mL」は「the initial dough volume is 1100mL」に修正します。ログ内の手順に初期の生地の量を記録するとあり、ダイヤルの体積を測る用途はなく、ほかに当てはまる単語もないためです。

推測が必要であれば、確定したとは言えません。

数値、単位、時刻、否定表現は、誤った推測が記録を変えてしまうため、決して修正せず、フラグを立ててください。

変更した場合はすべて、実行時の出力の後に、エントリー見出し、元の単語、新しい単語を記載した1行で報告し、誤った推測が分かるようにしてください。

単語を変更していない場合は、何も書かないでください。

単語が誤っているように見えても、文脈から正しい単語を確定できない場合はそのまま残し、実行の途中で質問せず、実行の最後にまとめて質問事項に追加してください。

実行で既に読み取る、または書き込むエントリーだけを修正し、誤りを探すために bake log 全体を調べてはいけません。

エントリーの見出しレベル

bake log 内では、エントリーは ## bake log セクションの下にネストされた H3 見出しです。

音声メモのエクスポートではエントリーが H2 になっているため、bake log に取り込む際はそれぞれ H3 に下げてください。

エントリー本文内の小見出しは H4 から始め、エントリーの兄弟見出しではなく、その子見出しのままにしてください。

## bake log セクションが作られる前のエントリーを含む古い bake log では、ネストするセクションがないため、エントリーを H2 のままにしてください。

重量の表記

音声メモは音声認識で文字起こしされるため、単位が単語で表記されたり、数値と単位の略記の間にスペースが入ったりします。

Zephyr エントリーを作成または編集するときは、すべての重量の値を、スペースのないコンパクトな形式に統一してください。

• 数値と単位の間にスペースを入れない
• grams ではなく g を使用する
• milliliters や ml ではなく mL を使用する

例：

• 「18 grams」→ 18g
• 「562 grams」→ 562g
• 「20 g」→ 20g
• 「2190 milliliters」→ 2190mL

これは、エントリー本文のあらゆる場所にある重量と体積に適用されます。材料の量、生地の重量、容器の風袋重量、測定値が対象です。

Zephyr のパン作りへの参照の記載

どのようなメモや表にも、Zephyr の番号だけを記載してはいけません（例：「Zephyr 13」）。

番号だけでは月をまたいで曖昧になるため、読み手が参照した時期によって「Zephyr 13」が6月13日か7月13日のどちらを指すのか分からなくなることがあります。

メモに記載する前に、必ず Zephyr キーを bake log のウィキリンクに解決してください。

• 良い例：[[bake log 5-13-2026-1]]
• 悪い例：Zephyr 13

これは表のセル、本文中の参照、その他あらゆる記述に適用されます。

event_time タグ

特定のパン作りの作業を記録する各 Zephyr エントリーには、本文の後の独立した行にインラインの event_time タグを付けます。

`event_time: YYYY-MM-DDTHH:MM:00`

event_time を付ける作業：

• 元種に餌を与える
• 元種がピークに達した
• ボウルから元種を取り出す
• 水と元種を混ぜる
• 生地にタンジョンを加える
• バルク発酵の開始（小麦粉を加えた）
• 塩を加える／塩を指で押し込む
• ストレッチ＆フォールドのセット
• ラミネーションフォールド
• プリシェイプ
• 成形
• 低温発酵の開始
• 焼成の開始／焼き上がり
• 温度プローブの挿入

event_time を付けないエントリー：

• 一般的なメモ、リマインダー、学んだこと
• 作業を伴わない測定値や重量の記録のみ
• 推測や振り返りのコメント

時刻の精度：

• 本文に時刻が記載されている場合は、その時刻を使用します
• 本文に時刻が記載されていない場合に限り、見出しのタイムスタンプを使用します
• ISO 8601 に変換します：YYYY-MM-DDTHH:MM:00

タグ付きエントリーの例：

### Friday, June 5, 2026 at 9:57 AM

For Zephyr 4-2, the starter peaked at 9:57 AM on June 5th.

`event_time: 2026-06-05T09:57:00`

タグなしエントリーの例（測定のみ）：

### Friday, June 5, 2026 at 10:59 AM

For Zephyr 4-2, the initial dough volume is 2100 ml.

元種のピーク到達時間

各焼成ログには、YAML ブロックを含む ## Starter peak duration セクションがあります。

fed: "[TBD]"
peaked: "[TBD]"
duration_to_peak: "[TBD]"
starter_remaining: "[TBD]"

焼成ログに導出に必要な情報がある場合にのみ、各フィールドに値を入力します。

推測したり、前の焼成ログの値を引き継いだりしないでください。

field	source	fill when
fed	feed_starter エントリーの event_time	時刻がわかる給餌エントリーがある
peaked	starter peaked エントリーの event_time	時刻がわかる元種のピーク到達エントリーがある
duration_to_peak	fed から peaked までの経過時間	fed と peaked の両方がわかる
starter_remaining	使用後に残った元種を記録した測定エントリー	焼成ログにその測定値がある

形式のルール：

• fed と peaked：ISO 8601、YYYY-MM-DDTHH:MM:00
• duration_to_peak：XhYm（例：11h52m）
• starter_remaining：簡潔な重量表記（例：1g）

必要な情報が焼成ログにまだない場合は、フィールドを "[TBD]" のままにします。

ワークフロー

Zephyr の焼成ログを扱う手順：

1. Zephyr キーを特定します（例：「Zephyr 28」または「Zephyr 3-2」）
2. 日数、任意の焼成番号サフィックス、現在の日付を使って、対応する焼成ログのファイル名を特定します
3. 焼成ログを読み、「For Zephyr N」のエントリーをすべて抽出します
4. 見出しのタイムスタンプではなく、イベントのタイムスタンプ（本文）を使用します
5. 焼成を参照する出力を作成するときは、[[bake log M-D-YYYY-N]] を使用します。Zephyr の番号のみを使ってはいけません

焼成ログに event_time タグを追加する手順：

1. 対象の焼成ログを読みます
2. 各 Zephyr エントリーについて、特定の作業を記録しているかどうかを判断します（上記のリストを参照）
3. 作業を記録している場合は、本文の最終行の後に event_time タグを追加します
4. 本文に時刻が記載されている場合はその時刻を使用し、記載されていない場合は見出しの時刻を使用します
5. すべてのタグを追加した後にコミットします

元種のピーク到達時間のブロックを更新する手順：

1. 焼成ログを読み、## Starter peak duration セクションを見つけます
2. 各フィールドについて、必要な情報が焼成ログのエントリーにあるかどうかを確認します
3. 導出できるフィールドにのみ値を入力し、それ以外は "[TBD]" のままにします
4. 更新後にコミットします

コンポーネント

このスキルは共有コアです。方式そのもの、ファイル名の解決、重量表記、event_time タグ、Starter のピーク時間ブロック、パラメーターの優先順位を扱います。

ベイクログに作用する動詞はそれぞれ独立したスキルであり、個別に呼び出せます。また、コア方式を変更せずに入れ替えられます。

スキル	対応する内容
[[zephyr-routing]]	任意のドキュメントにある Zephyr の記録を、適切なベイクログに移す
[[zephyr-grafana-links]]	## grafana セクション冒頭にある 2 つのダッシュボードリンク
[[grafana-bake-annotation]]	## grafana セクション内の annotate-grafana.py コマンドブロック

各動詞スキルは上記のルールを使用し、繰り返し説明しません。

リクエストでその動詞が必要な場合は、このスキルだけで作業せず、対応する動詞スキルを読んでください。

## grafana セクションは最後の 2 つのスキルで共有されています。冒頭にはリンクがあり、その下には注釈コマンドブロックがあります。

このセクションを編集する前に、呼び出すほうのスキルを読んで、担当する箇所を確認してください。

Zephyr をベイクログに適用する

「Apply zephyr」または「apply the zephyr skill to this bake log」は、複合リクエストです。

このスキルが担当するルールだけでなく、ベイクログ全体の標準状態が対象です。

次の順序で実行します。

1. 個別のベイク操作を記録したすべてのエントリに event_time タグを付ける — このスキル
2. ## Starter peak duration ブロック — このスキル
3. ## grafana セクション冒頭にある 2 つのリンク — [[zephyr-grafana-links]] スキル

リクエストでリンクが明示されていなくても、ステップ 3 を実行します。

これが複合リクエストである理由です。コアスキルを指定すれば、リンクの要素にも対応することになります。

次の 2 つの動詞は含まれず、それぞれ別の依頼として扱います。

• [[grafana-bake-annotation]] — ## grafana セクション内の annotate-grafana.py コマンドブロック
• [[zephyr-routing]] — あるドキュメントから別のドキュメントへのエントリの移動

スキルをまたいで処理を振り分けるのは、このリクエストだけです。

それ以外のリクエストでは、それぞれの動詞を指定し、上記の「コンポーネント」表に従ってください。

計測値の記録場所

ベイク中に計測したもの — タンジョンの重量、生地の体積、温度、出来高 — はすべて、## bake log セクション内の日付付きエントリに、新しいものから順に記録します。

その上にある、予防的バッファーチェック、タンジョンの調整、ベーカーズパーセント、手順などのひな形セクションには、レシピとその計算式を記載します。

ひな形は計画であり、次のベイクログにも引き継がれます。一方、日付付きエントリには今回のベイクで得られた観測結果を記載します。計測値をひな形に混ぜると、テンプレートとして使えなくなります。

ベイク中に観測した数値の表作成や記録を依頼された場合は、現在のタイムスタンプを付けた新しい日付付きエントリをエントリ一覧の先頭に追加し、ひな形には手を加えないでください。

ひな形セクションで、計算式を選んだ根拠として過去のベイク結果に触れることはできますが、今回のベイクの生の計測値を蓄積してはいけません。

ルヴァンの丸め

ルヴァンの計算結果が小数グラムになる場合は、必ず切り上げてください。46.5g のままにせず、47g と記載します。

スケールでは 1 グラム未満を計測できないため、実際には小数値に意味がありません。

x = ⌈(278 − 19) / 2⌉ = ⌈129.5⌉ = 130g のように、数式内で天井関数を使って切り上げを明示し、文章中の仕込み量にも丸めた値を使用してください。