thinkloom-openai-hackathon/.labyricorn/AGENTS.md

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.