Files

74 lines
3.7 KiB
Markdown

# 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 Thinkloom's exhibition page
and development log on Labyricorn.
- The Thinkloom repository is authoritative for this 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 communication
- When the user says **discussion only**, do not edit files, run mutating
commands, commit, push, request synchronization, or change external systems.
- An implementation request authorizes only its clearly stated scope. Ask
before changing project identity, content structure, schema, publication
status, or synchronization behavior.
- Do not commit or push unless the user explicitly requests it.
- Before pushing, explain that the pushed publishing content may be imported
into the public Labyricorn site.
- Preserve unrelated and uncommitted work. Never discard changes to obtain a
clean worktree.
## Content contract
- Use native Lektor records named `contents.lr`.
- Preserve `schema_version: 1` until a coordinated schema migration is approved
in both the project and Labyricorn site repositories.
- Do not add templates, models, plugins, workflows, executable files, generated
builds, or application state below `.labyricorn/`.
- Keep attachments inside the record subtree that owns them.
- Use UTF-8 text, `YYYY-MM-DD` dates, and stable lowercase hyphenated slugs.
- Do not use raw HTML, scripts, embedded credentials, or active third-party
content in Markdown fields.
- Treat published URLs as durable. Ask before renaming or removing a published
record; redirects or archival behavior may be required first.
## Security and synchronization
- Never store or print passwords, API tokens, refresh credentials, private keys,
`.netrc` contents, or other secrets in this directory.
- Never place a refresh credential in a URL, query string, tracked script, or
command example.
- Do not claim that content is public merely because a push succeeded. Report
push status and synchronization/publication status separately.
- After an explicitly authorized push that changes `.labyricorn/`, request at
most one refresh through the site repository's documented Gitea
`workflow_dispatch` endpoint. Use `POST` with `{"ref":"main"}` and an
`Authorization: token ...` header supplied from the approved
`LABYRICORN_REFRESH_TOKEN` environment or credential store.
- The endpoint is
`https://git.labyricorn.com/api/v1/repos/Labyricorn/labyricorn-site/actions/workflows/deploy.yml/dispatches`.
Never place its credential in the URL, this repository, an `AGENTS.md` file,
output, or logs. If the credential is unavailable, do not improvise: the
scheduled synchronization runs every 30 minutes.
- A successful dispatch only queues synchronization. Verify the Action result
and the imported revision on the public project page before reporting that
publication completed.
## Validation and handoff
- Parse every changed `contents.lr` file with Lektor's native record parser.
- Confirm required fields are present and referenced source commits exist.
- Run `git diff --check` and review the exact diff before committing.
- At handoff, report changed publishing records, validation performed, commit
and push status, and synchronization status if known.