Developing Rennet

Use this section to find the code that owns a Rennet behavior and the contract it must preserve. Start with the architecture pages, then follow the subsystem you are changing.

Built on T3 Code

Rennet stands on the shoulders of T3 Code, the open-source coding agent from T3 Tools. Its server, provider layer, and thread UI are the engine under every Rennet review: the chat beside each surface, the work orders Rennet dispatches, and the harness sessions that persist across a reload all run on T3 Code, vendored into this monorepo rather than reimplemented. Rennet would be a far smaller, slower thing to build without it, and the project is glad to build on such good work. A huge thank-you to the T3 Code team.

T3 Code is MIT licensed by T3 Tools Inc., and the upstream licence travels with the vendored snapshot unchanged. How the snapshot is taken, folded, and patched is in T3 Code vendoring; how the daemon runs it as an owned local process, the one Rennet’s own surfaces call the chat sidecar, is in the T3 Code sidecar.

Architecture tour

Read these pages in order when you need the whole system:

1. Architecture overview maps the apps, packages, processes, and review loop.
2. Architecture contracts defines the rules for patchsets, project context, persistence, and outbound work.
3. The lens pipeline explains how the delta packet reaches the Design, Sequence, Decisions, Flagged, and Noise drafters concurrently after the round-report boundary, and how bounded repair and deterministic validation freeze their boards.
4. Surfacing and routing covers model output, validation, instructions, and model assignment.
5. Hand off and the exits follows asks and the living drafts into a GitHub review, a work-order round, or a pull request.

Find a subsystem

Change	Read
Harness discovery, sessions, or events	Harness adapters and surfacing and routing
Prompt context or model assignment	Context assembly and model council
Definitions, references, or symbol lookup	Code intelligence
Board drafting, lint, or lens lanes	The lens pipeline
Board storage, elements, or the whiteboard protocol	How Rennet consumes @wboard/*
Asks, living drafts, or an exit	Hand off and the exits
Coding-agent rounds and successor patchsets	Hand off and the exits and Delta and generations
Repository discovery or settings	Repository bootstrap and settings and setup
The product images on rennet.dev	Marketing screenshots
Interface behavior	Design doctrine and the lens pipeline
Dependencies or build configuration	Dependency standard and monorepo map
How long a stage takes, and on which harness	Benchmarks

Source and authority

Contracts and rulings owns cross-cutting product decisions. Documentation architecture maps the narrower authorities. Promoted OpenSpec files define accepted behavior, and GitHub issues track active work.

The runtime is split across portable packages and thin applications. @rennet/server composes the daemon and command router. @rennet/client owns browser-safe connections to that daemon. @rennet/ui is the vendored component kit, and @rennet/app-ui owns the Rennet application interface built on it. apps/desktop and apps/mobile supply platform shells.

Work in the monorepo

Rennet uses pnpm and Nx. Query resolved configuration instead of guessing a project name or target:

pnpm nx show project <name> --json

The full local check is:

pnpm check

It runs formatting, architecture, licence, vendor-ledger, lint, typecheck, and build targets, then the test and dogfood-test targets together. The adapter build includes Rennet’s first-party native executable and therefore needs the host C toolchain described in the dependency standard. Before editing documentation, read the docs style guide and the good docs standard.