Update Labyricorn project and devlog

This commit is contained in:
2026-08-13 16:58:34 -07:00
parent 6c762c3b33
commit 14640faa15
7 changed files with 225 additions and 0 deletions
+42
View File
@@ -0,0 +1,42 @@
# Instructions for Labyricorn publishing content
These instructions apply to the entire `.labyricorn/` directory. More specific
instructions in `project/AGENTS.md` and `devlog/AGENTS.md` also apply within
those directories.
## Purpose and ownership
- This directory is the repository-owned source for the project's exhibition
page and development log on Labyricorn.
- This project repository is authoritative for the content. The Labyricorn site
imports it as read-only content.
- Read `.labyricorn/README.md` and the nearest scoped `AGENTS.md` before editing
a publishing record.
- Keep publishing changes focused. Do not alter application code merely to
support an exhibition or devlog edit unless the user separately requests it.
## Authorization and content contract
- Preserve unrelated and uncommitted work. Never discard changes to obtain a
clean working tree.
- Do not commit or push unless the user explicitly requests publication.
- Use native Lektor records named `contents.lr` and preserve `schema_version: 1`
until a coordinated schema migration is approved.
- Keep attachments inside the record subtree that owns them.
- Use UTF-8 text, `YYYY-MM-DD` dates, and stable lowercase hyphenated slugs.
- Do not add templates, models, plugins, workflows, executable files, builds,
application state, credentials, raw HTML, scripts, or active third-party
content below `.labyricorn/`.
- Treat published URLs as durable. Ask before renaming or removing a published
record; redirects or archival behavior may be required first.
## Security, synchronization, and review
- Never store or print passwords, API tokens, refresh credentials, private keys,
`.netrc` contents, or other secrets in this directory.
- Do not claim content is public merely because a push succeeded. Report push
status and Labyricorn synchronization status separately.
- Parse changed records, confirm referenced source commits exist, run
`git diff --check`, and review the exact publishing diff before committing.
- At handoff, report changed publishing records, validation performed, commit
and push status, and synchronization status if known.
+38
View File
@@ -0,0 +1,38 @@
# Labyricorn publishing content
This directory is the repository-owned source for Labyricorn Site's project
exhibition and development log on Labyricorn. The project repository remains
the source of truth; the Labyricorn site imports this content as read-only.
The content uses native Lektor records:
```text
.labyricorn/
├── AGENTS.md
├── README.md
├── project/
│ ├── AGENTS.md
│ ├── contents.lr
│ └── <optional image>
└── devlog/
├── AGENTS.md
├── contents.lr
└── <entry-slug>/
├── contents.lr
└── <optional images>
```
Rules:
- `project/contents.lr` uses the `project` model.
- `devlog/contents.lr` uses the `devlog` model.
- Each entry is a directory below `devlog/` containing a `contents.lr` record
using the `devlog-entry` model.
- Entry directory names are stable public slugs. Do not rename a published entry
without arranging a redirect on the Labyricorn site.
- Dates use `YYYY-MM-DD`; `source_commit` uses the full relevant commit ID.
- Publishing attachments stay inside the record subtree that owns them.
- Do not put credentials, builds, application state, or executable code here.
Editing these records does not itself prove that the public site synchronized.
Report repository publication and Labyricorn synchronization separately.
+57
View File
@@ -0,0 +1,57 @@
# Instructions for the Labyricorn development log
These instructions apply to `.labyricorn/devlog/` and help coding assistants
maintain the project's public development narrative safely.
## Format and ownership
- Keep the devlog index at `devlog/contents.lr` using `_model: devlog` and
`schema_version: 1`.
- Store each entry at `devlog/<stable-slug>/contents.lr` using
`_model: devlog-entry` and `schema_version: 1`.
- Use lowercase hyphenated entry slugs. Published slugs are durable public URLs;
do not rename or delete them without explicit approval and a redirect or
archival decision.
- Every entry must contain `title`, `date`, `author`, `summary`, `tags`,
`source_commit`, and Markdown `body` fields.
- Keep entry attachments in that entry's directory. Only PNG, JPEG, and WebP
images are accepted by the Labyricorn importer.
- Do not add templates, models, plugins, executable code, builds, application
state, credentials, or active third-party content below this directory.
## Content guidance
- Base entries on verifiable repository history, project documentation, and
implemented behavior. Do not invent motivations, results, release status,
user feedback, or completion claims.
- Explain the milestone, why it mattered, and what changed. Keep one main
milestone per entry and write a summary that works in a chronological list.
Do not merely expand a commit message or enumerate every changed file.
- Distinguish design and schema contracts from completed runtime behavior.
- Link to the relevant canonical commit using the repository's HTTPS web URL.
- Use the referenced commit's actual `YYYY-MM-DD` calendar date for retrospective
entries, not the date on which the prose was drafted.
- Set `source_commit` to the full lowercase 40-character commit ID most directly
associated with the milestone. It must be an ancestor of the published branch.
- Topics are comma-separated display labels. Unknown topics are allowed: the
site keeps them visible but unlinked. Do not create or edit the site's tracked
tag registry from this project repository.
- Use Markdown without raw HTML, scripts, embedded credentials, or active
external content.
- Multiple entries may share a date. The site resolves ties from source history;
do not invent timestamps or manual next/previous links.
- Do not rewrite older entries merely because the implementation later changed.
Add a new entry or a clearly labelled correction when historical context is
needed.
## Safety and review
- Preserve unrelated project files and uncommitted work. The devlog owns only
`.labyricorn/devlog/`.
- Do not commit or push unless the user explicitly requests publication.
- Before publication, verify claims against the referenced commit, validate all
records, check that the source-commit link uses the same full commit ID, review
the exact devlog diff, and confirm unrelated files are not staged in the
publishing commit.
- Prefer the repository-root `devlog_editor.py` for routine validation and safe
publication when it is available.
+7
View File
@@ -0,0 +1,7 @@
_model: devlog
---
schema_version: 1
---
title: Labyricorn Site development log
---
summary: Milestones and design decisions from the development of Labyricorn Site.
@@ -0,0 +1,21 @@
_model: devlog-entry
---
schema_version: 1
---
title: Just a test entry
---
date: 2026-08-13
---
author: Labyricorn
---
summary:
This is the summary
---
tags: test, topic, coolness
---
source_commit: 6c762c3b339bb6871ca138e5d95e39f95f220023
---
body:
This is the body
+33
View File
@@ -0,0 +1,33 @@
# Instructions for the Labyricorn project record
These instructions supplement `.labyricorn/AGENTS.md` and apply to the
`project/` directory.
## Record structure
- Maintain exactly one project record at `project/contents.lr` using
`_model: project` and `schema_version: 1`.
- Keep `project_id` stable. It is the durable identity used by the importer and
public URL.
- Ask before changing the repository URL, default branch, project status,
author, start date, or project identity.
- Store project-owned images in this directory and reference them by filename
from `contents.lr`. Only PNG, JPEG, and WebP images are accepted.
## Editorial guidance
- Write the exhibition page as a concise project narrative, not as a copy of
the repository README or as release documentation.
- Verify technical and status claims against the repository before editing.
- Distinguish completed work, formal design work, experiments, and future work.
- Do not manually add repository-derived commit, license, language, release,
issue, star, or fork metadata. The Labyricorn importer owns those values.
- Keep the summary suitable for listings and social previews.
## Review requirements
- Confirm all required project fields are present and any image reference stays
inside `project/`.
- Check Markdown links are intentional HTTPS links and prose makes no unsupported
claims.
- Validate the record and run `git diff --check` before committing.
+27
View File
@@ -0,0 +1,27 @@
_model: project
---
schema_version: 1
---
project_id: labyricorn-site
---
title: Labyricorn Site
---
summary:
This is the labyricorn-site project
---
status: active
---
started: 2026-08-11
---
author: Labyricorn
---
repository_url: https://git.labyricorn.com/Labyricorn/labyricorn-site
---
default_branch: main
---
tags:
---
body:
labyricorn-site project