Labyricorn - Thinkloom

Thinkloom

2026-07-16T00:00:00Z

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.

Establishing the writing workspace

2026-07-16T00:00:00Z

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

Building and preparing the Thinkloom desktop MVP

2026-07-17T00:00:00Z

The July 17 build brought together the milestones that turned Thinkloom from a writing-workspace framework into a reviewable native product.

First, Thinkloom became a Tauri 2 desktop application. React and TypeScript provided the interaction surface while the Rust service layer took responsibility for local persistence and native operations. The main workflow connected 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 product boundary was then narrowed deliberately. Hosted and browser-facing scaffolding were removed so Tauri became the sole application target. That made the local-first promise concrete: manuscripts, project state, and credentials belong on the writer's machine.

Model prompts also moved into documented, user-editable JSON templates. The application creates user-owned copies and reloads them before each request, with validation that leaves writing unchanged when configuration is invalid. That keeps model behavior inspectable rather than hidden in the application.

Finally, the project was prepared for Build Week with its demo, judging guide, license, collaboration record, and release-oriented documentation. The submission materials separate completed functionality from distribution work that still needs external assets or owner decisions.

Related milestones:

Formalizing the provenance contract

2026-07-18T00:00:00Z

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