LOGA Protocol BIBLE - 思想・執筆・構文の完全規約

33-ルールブック Public

最終更新: 2025/08/05

---
title: 'LOGA Protocol BIBLE - 思想・執筆・構文の完全規約'
slug: loga-protocol-bible
author: loga-protocol
status: public
category: rulebook
purpose: 'LOGA ProtocolとSyntextに関する全ての思想、アーキテクチャ、執筆ルール、構文仕様をこの一冊に集約し、唯一無二の公式な憲法とする。'
summary: 'これは思考の構造化を志す者、全ての航海士の必読書である。なぜこのシステムは生まれたのかという思想から、日々の執筆を支える七箇条、そしてAIとの対話を加速させる全ニーモニックまで。LOGA ProtocolとSyntextの全てを、この一冊に封じ込めた。'
tags:
    - loga
    - syntext
    - rulebook
    - bible
    - architecture
    - writing-guide
    - syntax
    - core-document
id: 20250805160805-6891add5c69503.53376412
---
0. (idea) **LOGA Protocol BIBLE - 思想・執筆・構文の完全規約** 📜

1. (s) **第一部：思想とアーキテクチャ (The Philosophy)**
 11. (s) **Syntextの存在目的**
  111. (g) 思考を構造化し、AIとの創造的対話を促進する。
 12. (s) **コアコンセプト：「二軸管理モデル」**
  121. (i) このナレッジベースは、以下の2つの軸で情報を整理・管理する。
  122.
| 軸 | 概念 | 役割 | 例 |
|:---|:---|:---|:---|
| **第一軸** | **エンティティ (Entity)** | **「誰が / 何が」**<br>思考の所有者・主体 | `webomega`<br>`daisuke-tsuneyoshi` |
| **第二軸** | **カテゴリー (Category)**| **「何を / どんな種類」**<br>思考のテーマ・形式 | `philosophy`<br>`progress-report` |
 13. (s) **アーキテクチャがもたらす価値**
  131. (g) **スケーラビリティ:** エンティティが増えても、カテゴリーは無秩序に増殖しない。
  132. (g) **発見可能性:** 異なるエンティティの思考が、同じカテゴリーで交差し、新たな発見や比較が生まれる。
  133. (g) **唯一無二の価値:** 一人の管理者（あなた）が全ての品質を管理する**「デジタル・ガーデン」**として、情報の価値を最大化する。

2. (s) **第二部：執筆の七箇条 (The Edicts)**
 21. (s) **第一条：目的なくして、執筆するなかれ**
  211. (i) 全てのstxtは、メタデータの `purpose` に**「この一行で、何を達成したいのか」**を明確に記述すること。
 22. (s) **第二条：思考の「家」を間違えるなかれ**
  221. (i) stxtを書き始める前に、**どのエンティティ（著者）に属する思考なのか**を自問すること。
  222. (s) **判断基準**
   2221. (q) これは**WebOmegaの事業**に関わる公式な思考か？ → `author: webomega`
   2222. (q) これは**システムや思想のルール**を定義するものか？ → `author: loga-protocol`
   2223. (q) これは**私個人の活動や思索**の記録か？ → `author: daisuke-tsuneyoshi`
 23. (s) **第三条：思考の「棚」は一つと心得よ**
  231. (i) `category`は、そのstxtが収まるべき、**最も適切な「棚」を一つだけ**選ぶこと。
 24. (s) **第四条：思考の「繋がり」を編むことを怠るなかれ**
  241. (i) `tags`は、カテゴリの垣根を越えて、**思考同士を繋げるための重要な糸**である。
 25. (s) **第五条：要約は「予告編」であると知れ**
  251. (i) `summary`は、単なる要約ではない。読者が「面白そう！読んでみたい！」と感じるような、**魅力的な映画の予告編**として書くこと。
 26. (s) **第六条：「下書き」と「完成品」を明確に区別せよ**
  261. (i) 書きかけの思考、推敲中の文章は、必ず `status: private` にしておくこと。
 27. (s) **第七条：思考の「死」を恐れるなかれ**
  271. (i) 書いてみたものの価値がないと感じたstxt、古くなって役目を終えたstxtは、**躊躇なく `status: archived` にすること。**

3. (s) **第三部：システムとファイルの規約 (The System)**
 31. (s) **基本原則:**
  311. (i) コンテンツ(`syntext`リポジトリ)とアセット(`syntext-assets`リポジトリ)を分離する。
 32. (s) **`syntext`リポジトリ構造:**
  321. (i) `contents/[タイプ]/[エンティティslug]/[stxtのID].stxt` というフラットな構造を基本とする。
 33. (s) **`syntext-assets`リポジトリ構造:**
  331. (i) `/images/cards/`: stxtのメインカード画像 (`[stxtのID].jpg`)
  332. (i) `/images/body/`: 本文埋め込み画像
  333. (i) `/images/profiles/`: プロフィール画像

4. (s) **第四部：メタデータの規約 (The Metadata)**
 41. (r) **!!パラメータの定義と役割!!**
  411.
| パラメータ | 必須/推奨 | 説明 |
|---|---|---|
| `id` | **必須** | `YYYYMMDDHHMMSS-xxxxxxxx`形式の不変ユニークID。 |
| `title` | **必須** | ドキュメントの正式名称。 |
| `slug` | **必須** | URLに使われる、アカウント内で一意な文字列。 |
| `status` | **必須** | `public` / `private` / `archived`。公開状態を制御。 |
| `author`| **必須** | 著者エンティティの`entity_slug`。 |
| `category`| **必須** | コンテンツが属する**唯一の分類**。主要な「棚」。|
| `purpose`| **必須** | この文書の核心的な目的。 |
| `summary`| **必須** | 人間向けの魅力的な要約（予告編）。 |
| `image` | 推奨 | カード画像のパス。`/syntext-assets/images/cards/[id].jpg`形式。|

5. (s) **第五部：記法の規約 (The Syntax)**
 51. (s) **基本装飾:** `*イタリック*`, `**太字**`, `!!赤太文字!!`
 52. (s) **リンク:** `[表示テキスト](URL)`
 53. (s) **隠しテキスト:** `??隠したいテキスト??`
 54. (s) **ニーモニック一覧 (Mnemonic Reference)**
  541. (s) **基本ニーモニック (絵文字系)**
   5411. (i) (v)→✅ (x)→❌ (i)→ℹ️ (s)→▪️ (idea)→💡 (!)→⚠️ ->→→
  542. (s) **カラーシグナル**
   5421. (i) (r)→🔴 (y)→🟡 (g)→🟢
  543. (s) **ドキュメントメタ**
   5431. (i) (title) (purpose) (summary) (benefit) (audience)
  544. (s) **5W1H**
   5441. (i) (what) (why) (when) (where) (who) (whom) (how)
  545. (s) **学習・補足**
   5451. (i) (hint) (exp) (example) (lesson) (conclusion)
  546. (s) **思考・戦略**
   5461. (i) (problem) (solution) (process) (strategy) (framework) (principle) (policy) (rule) (method)
  547. (s) **プロジェクト管理・分析**
   5471. (i) (scope) (stakeholder) (goal) (phase) (milestone) (feature) (requirement) (risk) (dependency) (result) (action) (next)
  548. (s) **ビジネス・評価**
   5481. (i) (invest) (metric) (kpi) (challenge) (win-win)
  549. (s) **SWOT**
   5491. (i) (strength) (weakness) (opportunity) (threat)

6. (s) **第六部：失敗から得た教訓 (The Lessons from Failures)**
 61. (s) **第一の教訓：ファイルは、最強のバックアップである。**
  611. (exp) DBはあくまで「索引」であり、コンテンツの「原稿」であるstxtファイルが存在することが、システムの復元力を飛躍的に高める。この**ファイルとDBを分離する設計思想**は、LTsiteの大きな強みであると再確認した。(CASE #1：データベース消失事件 より)
 62. (s) **第二の教訓：役割を厳密に分離し、権限を越えるな。**
  621. (exp) 本番サーバーは「公開の場」、ローカルPCは「開発の場」、GitHubは「保管庫」と、それぞれの役割を明確に分け、越権行為（本番サーバーでのGit管理コマンド実行など）を絶対に行わない。(CASE #2：本番環境git reset --hard事件 より)
 63. (s) **第三の教訓：データフローを定義し、一方向の流れを徹底する。**
  631. (exp) コンテンツは「Web→ローカル→GitHub」、コードは「ローカル→GitHub→Web」という、明確な一方向の流れを確立することが、未来の数千人のユーザーとこの事業そのものを守るための**最強の盾**となる。(CASE #2, #3 より)

LOGA Protocol BIBLE - 思想・執筆・構文の完全規約

SUMMARY