Add Labyricorn project and devlog content

.labyricorn/README.md

@@ -0,0 +1,37 @@
+# Labyricorn publishing content
+
+This directory is the source of Thinkloom's project exhibition and development
+log on Labyricorn. The application repository remains the source of truth for
+this content; the Labyricorn site imports it as read-only content.
+
+The content uses native Lektor records:
+
+```text
+.labyricorn/
+├── project/
+│   ├── contents.lr
+│   └── icon.png
+└── devlog/
+    ├── contents.lr
+    └── <entry-slug>/
+        └── contents.lr
+```
+
+Rules:
+
+- `project/contents.lr` uses the `project` model.
+- `devlog/contents.lr` uses the `devlog` model.
+- Each published 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` is the full commit ID most directly associated with the
+  entry. The site uses it to create a repository link.
+- Images and other publishing attachments must stay inside `.labyricorn/`.
+- Do not put credentials, generated builds, application state, or executable
+  code in this directory.
+
+The Labyricorn synchronization job reads content from an exact repository
+commit. Editing these records does not itself deploy the site; scheduled
+synchronization is the publication fallback.

.labyricorn/devlog/build-week-submission/contents.lr

@@ -0,0 +1,33 @@
+_model: devlog-entry
+---
+schema_version: 1
+---
+title: Preparing the Build Week submission
+---
+date: 2026-07-17
+---
+author: Christopher Chambers
+---
+summary: The project was packaged with its demo, judging guide, license, collaboration record, and release-oriented documentation.
+---
+tags: OpenAI Build Week, release, documentation
+---
+source_commit: 9c2ab17c2508f181ad7adee635cc4d21b37aa2b6
+---
+body:
+
+Preparing Thinkloom for OpenAI Build Week required more than producing a working
+binary. The submission needed to explain the problem, demonstrate the product
+without relying on private context, and document how Christopher and Codex
+collaborated during the build.
+
+This milestone added the submission narrative, a repeatable demo script,
+testing guidance for judges, and the AGPL-3.0 license. It also separated claims
+that could be demonstrated from release gates that still required external
+assets or owner decisions, such as code signing and bundled voice models.
+
+That distinction remains important to the project: completed functionality is
+documented plainly, while unfinished conformance or distribution work is not
+presented as done.
+
+[View the submission commit](https://git.labyricorn.com/Labyricorn/thinkloom-openai-hackathon/commit/9c2ab17c2508f181ad7adee635cc4d21b37aa2b6)

.labyricorn/devlog/configurable-model-prompts/contents.lr

@@ -0,0 +1,31 @@
+_model: devlog-entry
+---
+schema_version: 1
+---
+title: Making model prompts configurable
+---
+date: 2026-07-17
+---
+author: Christopher Chambers
+---
+summary: Conversation and drafting prompts moved into documented, user-editable JSON files that reload without rebuilding the application.
+---
+tags: prompts, models, configuration, user-control
+---
+source_commit: 58e5510445d7ab403d8df0792c29743a933531e0
+---
+body:
+
+Thinkloom's model behavior should not be a hidden, immutable part of the
+application. Conversation and drafting prompts were moved into structured JSON
+templates and documented as part of the project configuration.
+
+The application creates user-owned copies and reloads them before each request,
+so a technical writer can adjust instructions without rebuilding or restarting
+Thinkloom. Validation happens before a request is sent: invalid JSON or missing
+template variables produce a recoverable error and leave the writing unchanged.
+
+This work reinforced two of the project's recurring principles—model behavior
+should be inspectable, and failure should not silently alter a manuscript.
+
+[View the configurable-prompts commit](https://git.labyricorn.com/Labyricorn/thinkloom-openai-hackathon/commit/58e5510445d7ab403d8df0792c29743a933531e0)

.labyricorn/devlog/contents.lr

@@ -0,0 +1,7 @@
+_model: devlog
+---
+schema_version: 1
+---
+title: Thinkloom development log
+---
+summary: Milestones and design decisions from the development of Thinkloom.

.labyricorn/devlog/desktop-mvp/contents.lr

@@ -0,0 +1,33 @@
+_model: devlog-entry
+---
+schema_version: 1
+---
+title: Building the native desktop MVP
+---
+date: 2026-07-17
+---
+author: Christopher Chambers
+---
+summary: The workspace became a Tauri desktop application with a React interface, Rust service layer, local persistence, provenance, exports, and recovery behavior.
+---
+tags: Tauri, React, Rust, MVP
+---
+source_commit: b5e6eafa1c4e9b787250c15e6453c2d61dc8830c
+---
+body:
+
+The first desktop MVP moved Thinkloom from the workspace framework into a Tauri
+2 application. React and TypeScript provided the interaction surface, while the
+Rust service layer took responsibility for local persistence and native
+operations.
+
+This milestone connected the main workflow end to end: project state, idea
+curation, drafting, version history, provider boundaries, exports, backups, and
+an inspectable provenance trail. SQLite held live state while canonical files
+and hidden Git checkpoints provided durable, reviewable recovery points.
+
+The goal was not merely to wrap a web interface in a desktop shell. The native
+boundary made local files, operating-system credentials, atomic writes, and
+offline ownership part of the product itself.
+
+[View the MVP commit](https://git.labyricorn.com/Labyricorn/thinkloom-openai-hackathon/commit/b5e6eafa1c4e9b787250c15e6453c2d61dc8830c)

.labyricorn/devlog/native-only/contents.lr

@@ -0,0 +1,33 @@
+_model: devlog-entry
+---
+schema_version: 1
+---
+title: Choosing a native-only product boundary
+---
+date: 2026-07-17
+---
+author: Christopher Chambers
+---
+summary: Thinkloom removed its hosted and browser-companion paths so the implementation matched its local-first product promise.
+---
+tags: architecture, local-first, privacy
+---
+source_commit: 7866081c7882f8c59d137b126a6fe0278eda87df
+---
+body:
+
+During implementation, Thinkloom briefly contained hosted and browser-facing
+scaffolding alongside the desktop application. That created a mismatch with the
+product being described: a native, local-first writing studio with no required
+account or hosted companion.
+
+The project removed the Sites, Next, worker, and browser-companion paths and
+made Tauri the sole application target. This reduced the deployment surface and
+made the privacy boundary easier to understand: manuscripts, project state, and
+credentials belong on the writer's machine.
+
+The change was as much a product decision as a technical cleanup. A smaller,
+clearer architecture made it possible to state honestly what Thinkloom was—and
+what it deliberately was not.
+
+[View the native-only commit](https://git.labyricorn.com/Labyricorn/thinkloom-openai-hackathon/commit/7866081c7882f8c59d137b126a6fe0278eda87df)

.labyricorn/devlog/provenance-contract/contents.lr

@@ -0,0 +1,38 @@
+_model: devlog-entry
+---
+schema_version: 1
+---
+title: Formalizing the provenance contract
+---
+date: 2026-07-18
+---
+author: Christopher Chambers
+---
+summary: The provenance design advanced from a normative architecture into versioned schemas, fixtures, verification vectors, and canonical assertion envelopes.
+---
+tags: provenance, JSON Schema, verification, v0.4.0
+---
+source_commit: cb36bbc95895244f067934adc3531e733c0950db
+---
+body:
+
+Thinkloom's provenance goals require more than an activity timeline. The system
+needs stable records, explicit retention rules, deterministic verification, and
+a way to describe contribution relationships without making unsupported claims
+about authorship.
+
+The Stage 1 work documented the normative architecture and state machines. The
+Stage 2 package then introduced JSON Schema contracts, valid and invalid
+fixtures, canonicalization and event-chain vectors, release Merkle construction,
+key-rotation cases, and verification statuses.
+
+Version 0.4.0 extended that foundation with immutable provenance assertions,
+point-in-time evaluations, semantic registries, independent confidence
+dimensions, evidence classes, stable reason codes, and deterministic dependency
+invalidation vectors.
+
+The schema package is a formal design and test contract. The current native
+writer must not be described as conforming until the later implementation and
+fault-injection stages are complete.
+
+[View the v0.4.0 commit](https://git.labyricorn.com/Labyricorn/thinkloom-openai-hackathon/commit/cb36bbc95895244f067934adc3531e733c0950db)

.labyricorn/devlog/writing-workspace-framework/contents.lr

@@ -0,0 +1,30 @@
+_model: devlog-entry
+---
+schema_version: 1
+---
+title: Establishing the writing workspace
+---
+date: 2026-07-16
+---
+author: Christopher Chambers
+---
+summary: The first working framework established the conversation-first writing workspace and the visual language that would become Thinkloom.
+---
+tags: interface, writing-workspace, prototype
+---
+source_commit: c20e7a94fa8d1116e78afb8bec826e3ae593e0a3
+---
+body:
+
+Thinkloom began as a working writing-workspace framework rather than as a set of
+detached mockups. The first implementation explored how conversation, ideas,
+drafting, and project context could coexist without turning the editor into a
+generic chat window.
+
+The framework established the visual hierarchy and the central product idea:
+model assistance should remain visible and useful, while the writer controls
+what enters the manuscript. This initial version provided a concrete surface
+for testing the workflow before committing to the native application
+architecture.
+
+[View the originating commit](https://git.labyricorn.com/Labyricorn/thinkloom-openai-hackathon/commit/c20e7a94fa8d1116e78afb8bec826e3ae593e0a3)

.labyricorn/project/contents.lr

@@ -0,0 +1,45 @@
+_model: project
+---
+schema_version: 1
+---
+project_id: thinkloom
+---
+title: Thinkloom
+---
+summary: A native, local-first writing studio for moving from conversation to a versioned release while preserving an inspectable creative-process record.
+---
+status: active
+---
+started: 2026-07-16
+---
+author: Christopher Chambers
+---
+repository_url: https://git.labyricorn.com/Labyricorn/thinkloom-openai-hackathon
+---
+default_branch: main
+---
+logo: icon.png
+---
+tags: Tauri, React, TypeScript, Rust, SQLite, local-first, writing, provenance
+---
+body:
+
+Thinkloom is a native writing studio built for one writer. It supports a path
+from conversation and idea curation through drafting, revision, named versions,
+and release, while keeping the creative process inspectable.
+
+The application combines a Tauri 2 desktop shell with React and TypeScript,
+Rust services, SQLite state, canonical Markdown and JSON files, hidden Git
+checkpoints, operating-system credential storage, and atomic exports. It has no
+hosted or browser companion: the product boundary is deliberately local-first.
+
+The work began during OpenAI Build Week 2026. Product decisions emphasized
+preview-first model assistance, explicit user control, reversible operations,
+and provenance that records relationships without reducing authorship to a
+single percentage.
+
+Current development includes structured manuscript editing, configurable model
+providers and prompts, recovery snapshots, versioned releases, sanitized
+evidence exports, and a formal provenance schema package. The normative
+provenance design is documented; completing the native implementation and its
+fault-injection conformance remains future work.