Note

Markdown Notes for Hemisphere

HemisphereのNotesをMarkdownで管理し、制作ログと設計判断を継続的に残す

implementation-log #Hemisphere #Markdown #Notes #Astro #Publishing Back to notes

Context

HemisphereをCreative Engineering Labとして立ち上げたあと、次に必要になるのは継続的に記録を残せる仕組みである。

トップページやArchiveは、完成物や導線を見せる場所になる。 一方で、日々の実装、設計判断、移行作業、ワークフローの改善は、そのままでは流れてしまう。

そのため、NotesをMarkdownで管理し、Hemisphereの作業ログとして扱うことにした。

Decision

HemisphereのNotesは、Markdownファイルとして管理する。

記事は単なるブログではなく、次のような記録を残すための場所にする。 もちろん、そこにデイリー的なあまり重みのない記事も混ざっていくが。

Notes:
  implementation logs
  decision logs
  design notes
  migration records
  workflow experiments

Reasoning

Markdownは軽く、GitHubともAIとも相性がよい。 Astroで静的サイトとして扱いやすく、履歴もGitで追える。

Hemisphereでは、完成した成果物だけでなく、そこに至る判断や試行錯誤も重要になる。

なぜその構成にしたのか。 何を残し、何を移行しないと判断したのか。 AIや自動化をどのように使ったのか。

そうした情報をNotesとして残すことで、Hemisphere自体が継続的な作業場として機能する。

Implementation

まずは notes ディレクトリにMarkdownファイルを置く。

各記事にはfrontmatterを持たせる。

title:
date:
type:
tags:
excerpt:
draft:

初期段階ではCMS化しない。 Markdownを直接編集し、GitHub上で履歴を管理する。

必要になった段階で、Astro側にNotes一覧ページと記事ページを追加する。

Result

Notesの役割が明確になった。

Hemisphereは、完成したポートフォリオではなく、制作・設計・実装・検証の流れを残す環境になる。

Markdownで書くことにより、記事を書く行為そのものが開発ワークフローの一部になる。

Next

次に進めることは以下。

  1. Notes一覧ページを作る
  2. Markdown frontmatterの型を固定する
  3. draft: true の扱いを決める
  4. 記事タイプごとの表示ルールを決める
  5. Projects / Archive との接続を整理する

HemisphereのNotesは、更新情報ではなく、作業と思考のログとして育てていく。