ThreeLight Content is a public, text-first canonical source for the work, writing, research, and public identity associated with ThreeLight. It is designed to be consumed by multiple surfaces, rather than owned by any one of them.
It is not a ThreeLight Studio data directory, and it is not an asset repository. ThreeLight Studio is one consumer of this content; publishing platforms and future agent-facing tools may be other consumers.
ThreeLight Studio originally kept its own project, research, and log data. The work itself continued to change in its GitHub repositories, while the information shown in Studio had to be updated separately. Over time, the two could disagree.
Looking to GitHub as a possible source exposed a broader issue: the same project, writing, and profile information was being maintained in more than one place.
The issue was not limited to Studio. Public information is spread across GitHub, the ThreeLight Studio website, Threads, LinkedIn, Medium, and other current or future publishing surfaces.
The problem appears when each service becomes its own source of truth. A single piece of content then needs to be recreated, adjusted, and maintained for every place that presents it.
ThreeLight Content started as a solution to stale portfolio data, but the underlying problem turned out to be larger: public work, writing, research, and identity were fragmented across multiple platforms.
Instead of making ThreeLight Studio another source of truth, the content itself is separated from the surfaces that present it. This repository is the canonical authoring source; consumers choose how to discover, transform, and present the content they need.
That gives the repository a deliberately narrow role:
content + semantic metadata
|
+-- ThreeLight Studio (human-facing projection)
+-- publishing tools (Medium and other channels)
+-- future Agent / MCP consumers
.
├── AGENTS.md # Instructions for people and agents changing content
├── README.md
├── package.json # Bun commands for canonical content work
├── content/
│ ├── articles/
│ └── research/ # Canonical Markdown documents; more types appear when needed
├── scripts/ # Content creation, update, and validation commands
└── schema/
└── content-convention.md # Frontmatter and authoring convention
Only directories with a current purpose are included. New content types such
as projects, research, or logs may be added when their first real
document is introduced. A generated catalog or index is also intentionally
absent for now: it becomes useful once a consumer needs discovery without
reading document bodies. When introduced, it must be derived from the
canonical metadata rather than become a second authoring source.
Markdown is the canonical authoring format. Every content document starts with YAML frontmatter that separates its stable identity, general content metadata, and optional consumer projection hints. The metadata, not a Studio route or a directory name, defines what the content means.
The required fields are small by design. Natural-language documents also declare their language explicitly:
---
id: d0tP3397
slug: research-as-product
type: article
language: en
title: A human-readable title
summary: A concise, reusable description
createdAt: "2026-08-11T09:00:00.000+09:00"
updatedAt: "2026-08-11T09:00:00.000+09:00"
status: draft
---The filename carries the same identity as
<slug>--<id>.<language>.md. id is the immutable canonical identity;
slug is a readable repository label; title is an independently editable,
language-specific display string. Two authored language variants of one work
share id and slug but use distinct language suffixes.
Optional publication, topic, type-specific, and projection fields can be added when their information is known and useful. See schema/content-convention.md for the complete initial convention and an example document in content/articles/canonical-content-source--7sJjYFKa.en.md.
Use optional series only for a deliberately connected editorial set. It is
distinct from type and topics: for example, Studio's evolution records are
type: log with series: threelight-studio-evolution, while future product
logs may use different series values.
Projection metadata describes intended use by a consumer; it does not make that consumer the owner of the content. For example, an article intended only for Medium can live here with a publisher projection. No ThreeLight Studio application change is required to store it.
Use Bun commands so creation and body updates preserve identity and lifecycle
metadata. AI assigns the readable slug; the creation command assigns the
random canonical id.
bun run content:new -- --path content/articles --type article --slug canonical-content-source --language en --title "A canonical source for public content" --summary "A concise reusable description"
bun run content:variant -- --source content/articles/canonical-content-source--7sJjYFKa.en.md --language ko --title "공개 콘텐츠의 canonical source" --summary "독립적으로 작성한 한국어 소개"
bun run content:lines -- --file content/articles/canonical-content-source--7sJjYFKa.en.md
bun run content:update -- --file content/articles/canonical-content-source--7sJjYFKa.en.md --start-line 1 --end-line 0 --content-file /tmp/body.md --expected-body-sha256 <hash-from-content-lines>
bun run content:checkcontent:update addresses body lines only. It checks the body hash shown by
content:lines, replaces the requested range, and updates updatedAt in the
same atomic write. It never changes id, createdAt, or publishedAt.
The one-time Studio migration imports the public project and Atlas source records only. It does not consume or replace Studio at runtime. Provide the Studio repository root explicitly:
bun run content:migrate-studio -- --studio-root /path/to/threelight-studio --mode write
bun run content:migrate-studio -- --studio-root /path/to/threelight-studio --mode check
bun run content:migrate-studio -- --studio-root /path/to/threelight-studio --mode reconcilewrite creates only missing canonical documents and fails if an existing
target differs from the mapped source. check makes no changes and verifies
the committed documents still match the supported Studio source records.
reconcile is the deliberate, one-time bootstrap path for updating existing
non-curated Atlas documents when the migration gains newly supported canonical
metadata. It never changes canonical IDs or curated documents.
Studio root-relative Markdown links are normalized to
https://threelight-studio.com/... so the imported documents remain valid
outside the Studio host. Atlas block type is a Studio presentation hint and
is flattened into standard Markdown headings and bodies; format controls
whether the content is Markdown, text, Mermaid, or code. A future
threelight-* fence is reserved for content whose meaning cannot be
represented in standard Markdown.
Approved public-redaction exceptions live in
migrations/studio-public-content-curation.json. Each exception records the
document's immutable identity and a SHA-256 fingerprint of its approved
canonical frontmatter and body. The command reports only documents matching
that approved snapshot as curated; all other source-derived documents must
match Studio exactly. Use content:lines to obtain the body and document
hashes, and update the curated fingerprint deliberately whenever an approved
curated document changes.
Keep this repository suitable for normal Git review and history:
- Store Markdown, YAML, JSON, schemas, metadata, and other small text files.
- Reference images, video, and design files by external URL where needed.
- Do not commit large media files, design originals, build output, or an asset-hosting system.
- Do not add consumer-specific application code here merely to publish or display a document.
The repository intentionally does not currently provide an MCP server, publisher, universal publishing framework, completed semantic/TDM model, webhook automation, sparse checkout setup, asset hosting, or CMS UI. Those are consumer concerns to add only when a concrete need exists.
A consumer should treat content/ Markdown and its frontmatter as canonical.
It may initially read the documents it needs directly. When the collection is
large enough to require selective discovery, introduce a derived catalog with
document paths and summary metadata; consumers can consult it first and
materialize only the relevant documents. The catalog must remain a projection
of this source, never an independently edited replacement for it.
For contribution rules, including the rules that apply to agents, read AGENTS.md.