Learnings

Authority must be append-only in spirit

Putting a mutable revoked flag on a capability makes historical reconstruction depend on the latest row image. Step 1 instead treats grants as immutable and revocation as a separate attributable record.

Claims are lookup hints, not authority

claimedAuthority is useful because it prevents ambient privilege search and tells the resolver what the caller believes is relevant. The resolver still trusts only records already admitted by an authenticated authority store.

A schema-valid capability object supplied by a client is no more authoritative than text saying "I am allowed."

Delegation must attenuate every dimension

Checking only action names is insufficient. A child could otherwise widen targets, fields, risk, duration, or delegation depth. The reference resolver validates the entire chain and rejects any widening.

Risk belongs to the trusted boundary

Caller risk labels are informative. The resolver independently classifies the action. A request calling a consequential operation read does not make it safe.

Fields are part of authority

An adapter that may update a title does not therefore own a task. A participant that may read a summary does not therefore receive a hidden note. Field paths belong inside capability, context, and binding policy.

This becomes especially important for unified communications, where transport metadata, message bodies, identities, and private context have different disclosure and mutation rules.

Ordered streams beat a fictional global clock

The protocol needs deterministic reconstruction within a request, conversation, task, or relation. It does not need every event in the world to share one total order. Per-stream sequence and predecessor references are sufficient and easier to distribute.

Idempotency is durable state

An idempotency key is not merely a retry header. The durable request claim binds participant, key, and action digest. Exact retries replay; changed input conflicts; admitted requests without final receipts become explicit recovery cases.

Incomplete requests are normal

Stateless executors will disappear between admission and completion. Treating that condition as an error to hide invites duplicate action. The protocol returns pending plus a recovery recommendation and refuses to rerun silently.

Evidence is not a verdict

An artifact, successful test, or executor report may be strong evidence. It is still not the same record as an authorized determination that the objective was met. The evaluator boundary must remain visible.

Step 2 sharpened this further: a verified HARnest objective verdict must cite the canonical evidence records corresponding to domain-verified artifacts. A task status or artifact checkbox alone is not sufficient proof.

Disagreement is data

Two authorized reviewers may disagree. The system should preserve both verdicts and project uncertainty rather than choose one invisibly. Supersession must be explicit.

External systems need field-level authority

Object-level synchronization is too coarse. Each binding declares direction and external write mode per field. External deletion means the projection is missing, not that the canonical object should disappear.

Succession is continuity without identity fiction

A replacement model, device, custodian, or participant may inherit history and obligations by reference. It does not silently inherit identity or capability. New authority requires new authority records.

The reference kernel should remain boring

The first executable kernel is intentionally in memory. Its job is to expose contract mistakes before database behavior becomes doctrine. Har, Instant, SQL, local storage, and other engines should compete as implementations of the protocol rather than define it.

Persistence may be asynchronous without becoming semantic

A real HARnest adapter cannot assume that claims, event appends, evidence, verdicts, receipts, and reconstruction complete in one process or one synchronous call stack. Step 2 therefore names a persistence-neutral ProtocolJournal boundary whose methods may be synchronous or asynchronous.

That boundary does not permit a database to redefine replay, ordering, verification, or continuity. Storage latency and transaction mechanics are implementation facts; the protocol remains the observable contract.

Repository and branch names are separate namespaces

main is both a common branch name and the repository name prepace/main. Treating an unqualified main as obvious is a source-control hazard.

Step 2 now records repository and branch together:

prepace/main:main
prepace/harnest:codex/harnest-vertical-slice

HARnest also pins the canonical repository commit and individual schema/fixture blob identities. A branch merge cannot silently masquerade as a protocol upgrade.

A durable protocol spine can precede a normalized domain store

The supplied HARnest branch persisted its complete domain ledger as one server-only checkpoint. That made an existing in-memory product durable quickly, but unrelated concurrent writers could still produce broad last-writer behavior.

Step 2 did not pretend the checkpoint was already a final relational substrate. It added independently keyed request, event, evidence, verdict, and receipt documents beside it.

This creates a migration oracle:

legacy domain projection
        +
canonical protocol history
        -> normalized HarStore migration

The protocol spine can therefore be durable and exportable while the domain read model is still being normalized.

Physical storage does not determine logical record identity

Step 2 reused an existing generic, server-only Instant entity as a uniquely keyed document container for canonical protocol records. That avoided an unreviewed schema push.

An event and a receipt may temporarily share an entity type at the storage layer without becoming the same semantic object. Their Pre addresses, schemas, keys, and contracts retain their logical identity.

This is a migration bridge, not an endorsement of an untyped permanent database.

A model invocation is not an agent

HARnest persists agent:pre:repo-auditor-01 while recording OpenRouter, requested model, actual model, provider, usage, cost, input digest, and output digest as per-invocation execution metadata.

The same participant may therefore be instantiated through a deterministic fallback or a different provider without claiming that those substrates are numerically identical.

This is the first practical expression of model-agnostic participant identity, not yet the full agentic-permanence milestone.

Real local authority can remain boring

The first actual HARnest executor does not accept arbitrary model-generated shell commands. It performs fixed Git reads and a bounded allowlist of repository scripts, retains detailed output locally, and sends only sanitized summaries and digests remotely.

A boring controller is not a compromise. It is how the system proves that the web server and model can remain evanescent while consequential local authority stays explicit.

Extra capability code should fail closed rather than disappear

The supplied HARnest branch contained guarded documentation-write experiments beyond the read-only Step 2 claim.

Deleting them would discard useful design work; leaving them reachable would broaden authority accidentally. A server-only feature flag keeps the code and tests while every external entry point remains forbidden by default.

Deployment readiness is not execution evidence

A green build and READY Vercel deployment prove that code can execute in that environment. They do not prove:

• a live authenticated task lifecycle;
• a two-controller race;
• a local controller restart;
• a human evidence-verification decision;
• portable reconstruction from export.

Each claim requires its own evidence. Step 2 is therefore implementation-complete while operational acceptance remains explicit.

Next pivot

Run the live Step 2 acceptance sequence, then replace HARnest's whole-ledger checkpoint with independently transacted normalized entities or another conforming HarStore.

Only after that boundary is accepted should the system broaden through the Pre CLI, Linear, communications, Stow, or guarded write participants.