# 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.
- When an authenticated refresh mechanism is implemented and documented, use
  only its approved wrapper command and request at most one refresh for a pushed
  commit. Until then, do not invent or bypass a trigger mechanism.

## 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.