Canon workflows

1. Division of labour

The system deliberately keeps interpretation and transport separate. ChatGPT is the place where canon is discussed, reconciled, written, and given authority. The binary courier can be a local Codex checkout, as used here, or potentially ChatGPT Work for people who do not use Codex. Neither courier should be asked to decide canon.

2. Text canon stays in ChatGPT

Normal canon work does not go through Codex. ChatGPT reads the owning files, edits the appropriate canon/development/rendering documents through the GitHub connection, and commits those changes directly. The repository's AGENTS.md and ownership map define which files own which facts.

This keeps the local agent out of narrative decisions. The local checkout only becomes relevant when a binary asset must cross the gap between ChatGPT's file environment and Git.

3. Approved reference images → GitHub

Chat side

1. An image is explicitly approved as a canon or provisional reference.
2. ChatGPT preserves the original full-resolution file. It is not resized, recompressed, cropped, or converted.
3. The file is uploaded to Faie Canon Bridge/pending/ in Google Drive.
4. ChatGPT records the Drive file ID, direct-download URL, repository destination, byte size, SHA-256, and useful image diagnostics in .github/asset-import/pending.json.
5. Any accompanying canon/reference prose is updated separately through the normal GitHub text workflow.

Local side

The repository contains scripts/import-pending-assets. Codex only needs the instruction:

Import pending canon assets.

Repository instructions tell Codex to run:

bash scripts/import-pending-assets

The importer then:

1. refuses to run if the working tree is dirty;
2. runs git pull --ff-only;
3. downloads every pending asset with curl;
4. verifies both expected byte size and SHA-256;
5. copies the verified bytes to the declared canonical destinations;
6. clears the pending manifest only after the entire batch succeeds;
7. commits the assets and manifest update;
8. pushes the commit.

4. Alternative courier: ChatGPT Work

Codex is not conceptually required. For accounts that have ChatGPT Work, a Work thread can potentially replace the local Codex courier. Work is designed for longer multi-step tasks and can use Project context, connected apps, and files. On supported desktop configurations it can also work with local files and desktop apps when permission is granted.

The intended Work variant is straightforward: give Work the same Project context, have it read the pending manifest, retrieve the staged originals, upload the exact binaries to GitHub, verify them, and clear the manifest. That keeps the whole handoff inside ChatGPT rather than requiring a local repository checkout.

In other words: Codex is the current proven courier, not a requirement of the design. The actual contract is simply that some agent must move the exact staged bytes to GitHub without transforming them and must verify the expected hash before declaring success.

5. Private GitHub references → ChatGPT vision

The GitHub connector can authenticate to the private canon repository, but its ordinary file-fetch operations are text-oriented and do not return repository PNGs as viewable image payloads. A small GitHub Actions bridge solves the reverse direction.

The repository contains .github/workflows/export-canon-reference-images.yml. It runs only for pull requests whose head branch starts with asset-view/.

1. ChatGPT creates a temporary asset-view/* branch and opens a temporary PR.
2. The workflow checks out the private repository.
3. It collects image files under canon/**/references/.
4. GitHub packages them as the canon-reference-images Actions artifact.
5. The artifact is retained for one day.
6. ChatGPT downloads the artifact through the authenticated GitHub connection and can inspect the actual pixels.
7. The temporary PR is closed and the test branch is cleaned/reset.

6. Byte integrity

The image bridge treats SHA-256 as the authority for byte-for-byte preservation. Dimensions and file format are useful diagnostics, but they are not substitutes for the hash.

7. Security trade-offs

The Drive staging folder is intentionally configured as Anyone with the link → Viewer. This removes the need for Google credentials, OAuth, Drive software, or rclone on the local machine. The cost is that the staging URLs behave like bearer links: anyone who obtains one can read that staged asset while link sharing remains enabled.

The ChatGPT-side Google Drive connection may request broader Google-account authorization than this narrow workflow logically requires. The pipeline itself uses Drive staging only; Gmail, Calendar, Contacts, and other Google data are not part of the canon asset process.

The GitHub repository can remain private. The reverse-viewing workflow uses an authenticated Actions artifact with a one-day retention period rather than making repository images public.

8. The useful shorthand

Once the plumbing exists, the recurring human-facing operation is intentionally tiny:

Import pending canon assets.

On the tested Codex path, everything else is repository policy and deterministic machinery. A Work-based courier could use the same manifest and integrity rules without requiring a local Codex checkout. That is the design goal: let humans and language models argue about canon, and let boring machinery move bytes.

9. Site layout convention

On the Faië 魔法 website, the full-body Faië artwork is a persistent visual separator for the footer. On desktop it may remain fixed alongside the main content; on mobile it moves into normal document flow. In either presentation, Faië belongs at the end of the page content, immediately before the footer/license area. Do not place ordinary navigation, documentation cards, or other page content between the Faië figure and the footer.