---
title: "Projects"
description: "The recognized system registry and ownership boundaries."
navLabel: "Projects"
order: 60
nav: false
navGroup: "Reference"
eyebrow: "System registry"
status: "current"
theme: "main"
visibility: "public"
---

The machine-readable registry is available at [registry/projects.json](/registry/projects.json). The protocol contract registry is at [registry/protocol.json](/registry/protocol.json).

## `main`

- Repository: `prepace/main`
- Canonical branch: `main`
- Role: canonical system map, protocol constitution, decisions, schemas, conformance references, account contract, and content renderer
- Status: Steps 0 and 1 complete; HARnest Step 2 implemented; live acceptance and account implementation tracked separately

`prepace/main:main` contains the protocol constitution, compact conformance references, the HARnest Step 2 fixture, and the canonical decision that Pre Accounts are durable holons while `*.pre.bi` hostnames are external network bindings. It does not own production task orchestration, customer records, local repository authority, or the HARnest domain store.

## HARnest

- Repository: `prepace/harnest`
- Product source branch: `main`
- Role: durable relational agency, task rooms, account-scoped work, controller relay, evidence, review, handoff, and execution coordination
- Status: Step 2A–2F implementation merged; copy-safe handoff implemented; live operational acceptance, normalized domain persistence, and account scope remain

HARnest pins the canonical action protocol to repository `prepace/main` by commit and canonical blob identities. Its product code includes public and private surfaces, controller and operator boundaries, request-scoped Instant protocol records, a bounded local repository audit, optional evanescent OpenRouter synthesis, evidence-linked objective verdicts, reconstruction, export, and a copy-safe cold-start handoff.

The inherited whole-ledger checkpoint remains the current HARnest domain projection store. It is not the final HarStore architecture and must not contain unrelated production accounts.

The first handoff distinguishes implementation provenance from workspace, room, task, and run scope but is explicitly account-unbound until HARnest admits canonical Account and hostname-binding records.

## Pre Accounts and `*.pre.bi`

- Repository owner: no customer repository; canonical contract in `prepace/main:main`, runtime records in account-aware product stores
- Role: durable custody, authority, billing, export, restore, and succession boundary
- Network surface: reversible `<slug>.pre.bi` or custom-domain bindings
- Status: canonical contract defined; implementation pending

A Pre Account may represent a person, family, organization, archive, community, or separately governed initiative. Customer and account records must not be committed to `prepace/main`, `prepace/harnest`, or one Git branch per customer.

## Presertion

- Repository: `prepace/presertion`
- Role: durable relational knowledge, assertions, evidence, contradiction, and provenance
- Status: independent active development; repository state is authoritative

Presertion will eventually provide the knowing layer inside an authorized account while retaining source custody, uncertainty, disagreement, and correction.

## Stowaway and Stow

- Repository: to be confirmed in this registry before new canonical implementation work
- Role: browser preservation tool and broader encounter and local-capability environment
- Status: existing extension workstream; Stow protocol not yet extracted

## Har

- Repository: none
- Role: realtime relational substrate and storage-compatibility contract
- Status: contract implemented through memory and Instant-shaped HARnest boundaries; fork decision deferred until normalized persistence, account isolation, and live concurrency evidence exist

## External adapters

Linear, Brevo, Gmail, Microsoft, GitHub, Vercel, Cloudflare, Backblaze, payment providers, OpenRouter, Instant, and model providers remain replaceable adapters or execution substrates. Their objects, accounts, deployments, domains, and model names do not become canonical Pre Account or participant identity merely through integration.

Brevo may provide sending, inbound parsing, Conversations operations, and delivery evidence. It does not own the canonical Pre inbox or relationship history.