Roadmap

Operating discipline

Contracts before adapters. One complete loop before a platform. One holon before multi-tenancy. A concrete incompatibility before a fork. Paid delivery before speculative self-service.

Commercial implementation may begin through manually provisioned and isolated accounts before wildcard automation exists. Revenue does not certify architecture; architecture does not prove demand.

Step 0 — Establish main

Status: complete

• canonical context, status, principles, architecture, ontology, protocol, security, roadmap, glossary, decisions, and learnings;
• machine-readable schemas and registries;
• dynamic Markdown-to-JSON content compiler;
• one nested catch-all page renderer;
• generated navigation plus reachability validation;
• JSON and Markdown projections;
• fail-closed publication and schema validation;
• Vercel production at main.pre.bi.

Cross-cutting surface direction

Do not evolve PageDocument into arbitrary React serialized as data. Generalize the Step 0 pattern into trusted, purpose-specific surface projections.

canonical account records / Har state
        -> trusted projection resolver
        -> typed surface document
        -> renderer
             -> semantic SSR content
             -> trusted client islands
             -> data views
             -> optional scene / shader layer

Long-term surfaces may use semantic layout, versioned design packs, trusted forms and buttons, capability references, data-bound mailboxes and workspaces, and declarative 2D and 3D scenes. Stored content never supplies arbitrary executable React or JavaScript.

Step 1 — Shared Pre protocol

Status: complete

The protocol has storage-neutral TypeScript contracts, published JSON Schemas, invariants, a compact in-memory conformance kernel, a persistence-neutral journal boundary, and regressions covering the complete request lifecycle.

Step 1A — Addresses and envelopes

Status: complete

• bounded canonical Pre address grammar;
• address segments explicitly non-authoritative and non-hierarchical;
• pre.action.v1 and pre.result.v1;
• claimed authority separated from trusted resolved authority;
• admission, execution, and objective outcome separated.

Step 1B — Authority and capabilities

Status: complete

• admitted identity bindings and memberships;
• immutable context grants and capabilities;
• exact action, target, field, risk, and time bounds;
• full-chain attenuating delegation;
• separate immutable revocation records;
• trusted risk reclassification;
• fail-closed resolution from authority-store state only.

Step 1C — Events, receipts, and idempotency

Status: complete

• immutable per-stream events with sequence and predecessor;
• durable participant, key, and action-digest request claims;
• exact replay, changed-input conflict, and incomplete-request recovery;
• immutable final receipts binding request, result, and event digests;
• reconstruction after executor loss.

Step 1D — Evidence and objective outcomes

Status: complete

• attributable evidence records;
• explicit trusted objective evaluators;
• durable verdicts with evaluator authority and evidence references;
• explicit supersession;
• preserved disagreement;
• evidence never promotes itself into truth.

Step 1E — External bindings and succession

Status: complete

• reversible canonical and external bindings;
• field-level direction and adapter write modes;
• explicit conflict records;
• canonical survival after external deletion;
• scoped succession records;
• no implicit identity or authority transfer.

Step 1F — Reference protocol loop

Status: complete

The reference kernel proves:

identify
  -> claim request
  -> resolve bounded authority
  -> execute a field-limited read
  -> record events and evidence
  -> optionally evaluate the objective
  -> issue result and receipt
  -> terminate
  -> reconstruct or replay with a replacement kernel

Step 2 — HARnest vertical slice

Status: implementation complete; live acceptance pending

Repository boundary:

prepace/main:main
  canonical protocol

prepace/harnest:main
  HARnest product source of truth

Step 2A–2F implements:

• an exact lock from HARnest to the canonical protocol commit and schema and fixture blob identities;
• canonical action and result envelopes and event, evidence, verdict, and receipt records for task creation, task claim, event append, evidence, usage, synthesis, and final review;
• exact replay and changed-input idempotency conflicts;
• request-scoped, individually keyed Instant protocol documents;
• a real local repository-readiness executor using fixed Git reads and allowlisted npm scripts;
• sanitized remote evidence plus detailed local-only artifacts;
• optional OpenRouter structured synthesis with deterministic fallback;
• persistent agent identity independent of gateway, model, and provider selection;
• operator-controlled verdicts that cite canonical evidence linked to verified artifacts;
• reconstruction and authenticated protocol export;
• guarded-write primitives disabled by default;
• copy-safe cold-start handoff with explicit implementation and record scope;
• patched production dependencies and a permanent high-severity audit gate.

Step 2G — Operational acceptance and normalized persistence

Status: next

Run and record one complete live task using operator-held credentials and a trusted local checkout:

1. Create a task against the configured Instant app.
2. Race two independent controller claims and observe exactly one winner.
3. Terminate the controller mid-lifecycle and resume through explicit replay and reconstruction.
4. Produce deterministic repository evidence and optional evanescent synthesis.
5. Verify required artifacts and issue the evidence-linked operator verdict.
6. Export canonical protocol bundles and reconstruct the same outcome.

Then replace the inherited whole-ledger checkpoint as HARnest's primary domain read and write model with independently transacted normalized entities or another conforming HarStore.

Acceptance requires the same task lifecycle and protocol export to pass against memory and Instant without unrelated concurrent mutations overwriting one another.

Step 2H — Pre Account and network-binding contract

Status: canonical contract complete; implementation pending

• define a Pre Account as the durable custody, authority, billing, export, restore, and succession boundary;
• use an immutable opaque account: address;
• treat *.pre.bi and custom domains as reversible external bindings;
• require account scope before reading or mutating account-owned records;
• keep cross-account disclosure behind explicit grants and capabilities;
• preserve account identity across isolated, shared, dedicated, and federated deployment topologies.

The current HARnest handoff remains account-unbound until this contract is implemented in admitted runtime records.

Step 3 — Account-scoped HARnest and first account holon

Implement the smallest complete account slice in prepace/harnest:main:

• account and hostname-binding records;
• account membership and fail-closed account resolution;
• account-scoped workspace, rooms, tasks, runs, artifacts, protocol queries, exports, and handoffs;
• an account surface with public or member home, /work, /records, /people, /files, and /settings placeholders or bounded projections;
• complete account export;
• no cross-account query path.

Provision one real account manually with an exact <slug>.pre.bi binding and isolated data. Do not point a wildcard domain at the current global checkpoint-backed HARnest store.

This is the first product holon and the first safe target for paid account activation or implementation work.

Step 4 — Minimal unified communications slice

Treat communication as an account-scoped relational timeline rather than a provider inbox.

Initial work should:

• admit external transport bindings for Brevo and one user mailbox source;
• normalize accounts, addresses, people, organizations, messages, conversations, attachments, delivery attempts, and delivery events while preserving provenance;
• support an opaque inbound address on a receiving subdomain such as reply.pre.bi;
• present email in a chat-like account timeline;
• keep sender identity and transport visible so replies use the appropriate account, persona, and provider;
• allow a message to nominate a HARnest task without making message text executable;
• retain external provider IDs as bindings rather than canonical identity.

Brevo may provide sending, inbound parsing, and delivery evidence. It is not the canonical Pre inbox.

Step 5 — Three lighthouse accounts and paid delivery validation

Use manually provisioned account holons for three bounded deployments, including internal or mission accounts and at least one paid external account.

Each engagement should move through:

Account Census
  -> Mission Model or bounded implementation
  -> account-scoped work and evidence
  -> accepted deliverables
  -> capacity transfer or stewardship
  -> complete export

Measure:

• willingness to pay and signed bookings;
• direct delivery cost and SME hours;
• operator time;
• account activation time;
• recurring stewardship conversion;
• security and privacy incidents;
• common records and surfaces across all three accounts.

Standardize only what repeats. Do not build public self-service merely because one bespoke account works.

Step 6 — Pre CLI

Expose a small, auditable shell interface for identity, account selection, context, rooms, tasks, approvals, preservation, evidence, search, reconstruction, export, and synchronization using the same action protocol.

Do not begin consequential CLI actions before Step 2G's durable domain boundary is accepted. The CLI must resolve account scope explicitly and must not accept a hostname or environment variable as authority.

Step 7 — Linear projection

Keep HARnest canonical while projecting selected account tasks, statuses, comments, and projects into Linear through reversible, field-scoped bindings.

Step 8 — Stow protocol and Stowaway adapter

Specify encounter, preserve, relate, assert, correct, attach-to-task, use-as-evidence, request-capability, act, and receipt operations before rebuilding the browser.

Every durable Stow record resolves an account or an explicitly personal local custody boundary. Encounter does not mean preserve everything.

Step 9 — Presertion integration

Let HARnest evidence nominate attributable assertions. Let Presertion knowledge become bounded account and task context without turning agent inference into truth.

Step 10 — Shared wildcard account platform and passkeys

Only after Step 2G and the three-account validation:

• route *.pre.bi through a trusted hostname-binding resolver;
• replace shared secrets with passkey-backed identities and multi-user memberships;
• enforce account scope in every storage query, cache key, protocol query, background job, and export;
• add account quotas, entitlements, backup, restore, deletion, observability, and abuse controls;
• support custom domains as reversible bindings;
• retain dedicated deployments for accounts whose custody or sovereignty requires them.

A shared wildcard application is an implementation optimization. It does not redefine the account.

Step 11 — Decide whether Har needs a fork

Evaluate the accepted normalized and account-scoped implementation against self-hosting, authority resolution, immutable events, offline sync, export, succession, auditability, normalized queries, tenant isolation, and schema evolution.

Har remains a protocol boundary until a concrete incompatibility justifies code ownership.

Step 12 — Agentic permanence, bounded avatars, and direct connection

Migrate one persistent participant address between model providers while preserving attributable history, recording differences, and making no false claim of identical substrate.

Then test one bounded account avatar or introduction flow and one availability proposal:

participant A proposes a bounded interaction
  -> account and relationship policy resolve
  -> participant B or avatar answers, schedules, or escalates
  -> only necessary context is disclosed
  -> action and connection leave receipts

Step 13 — Federation and commercial hardening

Add:

• portable and self-hosted account implementations;
• account-to-account grants and federated relationships;
• subscriptions, storage and communications quotas, and model usage controls;
• trust tiers and verified custody services;
• training and certification for external delivery partners;
• sponsored public-benefit accounts;
• regional deployment and data-residency options;
• tested disaster recovery and succession.

Commercial delivery begins before this step. This step hardens repeatable platform economics and federation; it is not permission to postpone revenue validation.

Proof points

Pre can define a safe action

addresses + authority + events + evidence + continuity + reference kernel

Pre can coordinate

Step 1 protocol + accepted HARnest lifecycle + account-scoped work + CLI

Pre can hold one governed world

Pre Account + *.pre.bi binding + public/private projections + complete export

Pre can operate across existing software

communications + Linear + Stow + reversible bindings

Pre can become a product

three paid or lighthouse accounts + recurring stewardship + shared wildcard platform

Pre can preserve continuity across institutions and time

Presertion + physical and digital custody + federation + succession + model-independent participants