Status

Current repository

prepace/main:main is a Next.js 16 application connected to the Vercel project main.

• Live canonical domain: main.pre.bi
• Secondary Vercel alias: main-pre.vercel.app
• Current milestone: HARnest Step 2 implementation merged; live acceptance remains
• Current canonical decision: Pre Accounts are durable holons and *.pre.bi hostnames are reversible network bindings
• Next bounded milestone: live HARnest acceptance, normalized domain persistence, then one manually provisioned account holon

Repository qualification

prepace/main:main
  canonical map and protocol constitution

prepace/harnest:main
  HARnest product source of truth

Feature branches and historical integration branches do not replace either source of truth.

HARnest pins the canonical protocol to prepace/main:main commit dd14107c85b9400d0c3d98aa2b124dd0a243884c and pins the registry, schema, and conformance-fixture blob identities. Later canonical documentation decisions do not silently upgrade the locked action protocol.

Existing related systems

HARnest

prepace/harnest:main contains the first substantial HARnest task-room product rather than only the original Mbuyu query bridge.

The merged Step 2 implementation includes:

• public and private task-room projections;
• operator and controller authentication;
• tasks, runs, participants, memberships, events, messages, approvals, artifacts, context grants, scope requests, and usage views;
• canonical Pre action and result envelopes and event, evidence, verdict, and receipt records for the bounded read-only lifecycle;
• exact replay and changed-input idempotency conflicts;
• request-scoped, individually keyed protocol documents in Instant or the deterministic test store;
• controller reconstruction and authenticated protocol export;
• a real local repository-readiness executor with fixed Git reads and allowlisted npm scripts;
• optional OpenRouter structured synthesis with a deterministic fallback;
• a persistent synthesis participant address distinct from the selected model and provider;
• verified objective verdicts that cite canonical evidence linked to domain-verified artifacts;
• guarded-write primitives that fail closed by default;
• a production dependency audit and full CI gate.

The first copy-safe handoff projection distinguishes product and protocol implementation provenance from record scope. Its current record scope is deliberately account-unbound; it does not claim that a customer, family, or organization account or *.pre.bi hostname has been admitted.

Pre Accounts

The canonical account and hostname-binding decision now exists in prepace/main:main.

No production Pre Account implementation is claimed yet. In particular, HARnest does not yet provide:

• canonical account records;
• account hostname bindings;
• account-scoped memberships and sessions;
• account-scoped protocol queries and exports;
• tenant isolation;
• account backup and restore;
• billing or entitlement records;
• wildcard account provisioning.

The current HARnest deployment must not be treated as a multi-tenant account platform.

Presertion

prepace/presertion is an independently developed web-native, local-first epistemic database and hypergraph. Its own repository state remains authoritative.

Stowaway and Stow

Stowaway exists as a browser-extension workstream for tab discipline, preservation, Reader behavior, and graph-oriented context. Stow is the proposed broader browser and local environment. The Stow protocol and browser product are not implemented here.

Har

Har remains an architectural contract and Instant compatibility boundary, not a claimed fork.

Step 2 produced the first concrete substrate evidence: Instant can host server-only canonical protocol documents, but the inherited HARnest domain UI still reads and mutates a whole-ledger checkpoint. The next persistence task is to replace that checkpoint with independently transacted normalized entities or another conforming HarStore.

What Step 0 and 0.1 implement

• canonical root documents, decisions, sources, and registries;
• dynamic navigation and route reachability validation;
• filesystem content-source adapter;
• bounded Markdown-to-JSON compiler;
• versioned and schema-validated PageDocument projection;
• trusted semantic theme registry;
• one catch-all server-rendered page component;
• JSON and Markdown machine views;
• fail-closed public and private publication;
• canonical production delivery at main.pre.bi.

What Step 1 implements

Addresses and envelopes

• one bounded Pre address grammar;
• non-authoritative address namespace semantics;
• pre.action.v1 and pre.result.v1;
• admission, execution, and objective outcome as separate states.

Authority and context

• immutable identity binding and membership records;
• immutable context grants and capabilities;
• separate immutable revocation records;
• full-chain attenuation for delegation;
• exact action, target, field, risk, and time bounds;
• trusted risk reclassification;
• authority resolution from admitted store records only.

Durable execution records

• request claims and canonical digests;
• ordered per-stream events;
• exact idempotent replay;
• changed-input conflict;
• explicit incomplete-request recovery;
• immutable final receipts.

Evidence and continuity

• attributable evidence;
• explicit objective evaluators and verdicts;
• preserved disagreement and supersession;
• reversible field-level external bindings;
• canonical survival after external deletion;
• succession without implicit authority transfer.

Reference implementation

• an in-memory authority store, protocol journal, resource store, and kernel;
• one field-limited read executor;
• reconstruction and replay after replacing the executor and kernel process;
• published pre.protocol-records.v1 union schema;
• a persistence-neutral journal boundary and HARnest conformance fixture.

What Step 2 still must prove operationally

The implementation exists, but these observations require operator-held credentials and a trusted local checkout:

1. Create and complete one live authenticated task against the configured Instant app.
2. Race two independent controller claims and observe exactly one winner.
3. Terminate and restart the local controller during that task, then reconstruct without duplicated effects.
4. Verify the required artifacts, issue the operator verdict, and export the resulting canonical bundles.
5. Re-import or reconstruct the same outcome from the exported protocol state.
6. Replace the inherited whole-ledger checkpoint as the primary HARnest domain read and write model.

Until those observations are recorded, Step 2 is implementation-complete but not fully accepted as a production-durable system.

Current deployment constraint

Before normalized persistence and account-scoped authorization exist, early real accounts must be manually provisioned with isolated data boundaries. A shared wildcard application may follow only after tenant isolation, account-scoped queries, backup, restore, and concurrency behavior are accepted.

What is not implemented yet

• normalized production-grade HARnest domain persistence;
• canonical Pre Account records and *.pre.bi bindings;
• passkey or multi-user account identity;
• a production controller fleet and lease and recovery service;
• account-scoped communications adapters or inbox;
• Pre CLI;
• Linear integration;
• Stow browser capture;
• Presertion assertion integration;
• durable handoff artifacts with supersession;
• model-provider migration acceptance;
• payments, subscriptions, entitlements, or wildcard provisioning.