Forem: Chris

Agreement Is Not Contract. It's the Structure of Reality.

Chris — Thu, 26 Mar 2026 14:10:53 +0000

Art is the target: not software, not wealth, not status.

Consciousness is the medium.

Every atom of this body.
Every attention unit.
Existence itself.
The inherent bliss of pure awareness.

The sculptor's tool, shifting, spreading—deployed for one purpose: creating art.
Consciousness painted.

Sure, we start with business contracts, software development milestone agreements, NDAs, and consulting accords. But that's a remnant of my attorney past.

Easy entrée into a world of overlapping Agreement.

It's deeper than that.

Papre isn't about Agreement for the sake of business efficiency.

A software developer agrees with her client. Easy.

You agree to follow the laws of your country.
Yes, you agree.
You're free to violate the law, although under duress.

Bodies agree to fall at 9.8m/s².
Planets orbit stars.
E=mc².

Papre is about Agreement as the connective tissue of the Human organism, of material reality itself.

It's axiomatic in this system.

It isn't Truth.

It's a way of ordering the world.

And when we order the world coherently in this way, as a system of Agreements, we can create an API for the world.

APIs are usually seen as a way for the world to interface with software.

Papre is different.
Papre is the world's API.

By ordering the world in this way, software becomes the world's graph, a system of edges connecting previously disparate components of material reality into explicit systems that can be observed and shifted like a painter moving paint with her brush, eventually manipulating the very structure of reality.

Crazy? Yes.

But you already live inside this web of Agreements.
Weave it yourself.

What's Been Shipping

A month of quiet violence against the blank canvas:

Mobile QR signing — you scan a code, you sign from your pocket. Agreements escaped the desktop
Facilitated agreements — a third party can now weave an agreement between two others, like a matchmaker who steps aside once the vows are spoken
The document editor became an instrument — bubble menus, slash commands, drag sections like rearranging verses, AI that reads your document and fills the blanks
Chain-agnostic architecture — Papre no longer cares which blockchain you're on. Switch chains with an environment variable. The protocol is indifferent to the substrate
API v1 — the first public interface. Other software can now create and query agreements programmatically. The world's API gets its own API
Embed profiles — agreement flows that live inside other websites, like a clause that nests inside a stranger's sentence
A design system that breathes — warm grays, glass navigation, teal gradients. The interface started looking like something you'd want to touch
The repo split in half — web and API separated into independent deployments. Faster. Cleaner. Two lungs instead of one
Demo mode — a sandboxed reality for showing the product without disturbing the living system

How We Fixed Firefox's localStorage Race in Playwright: Two Navigation Helpers

Chris — Tue, 24 Feb 2026 19:47:57 +0000

TL;DR

Firefox's addInitScript can race against page rendering when seeding localStorage for E2E tests. We fixed it by splitting navigation into two helpers: gotoPage (fast, commit) for interactive flows and gotoAgreementPage (reliable, domcontentloaded) for data-dependent pages.

The Problem

We use Playwright's addInitScript to seed localStorage with mock agreement data before each test. This works perfectly in Chromium — the init script runs, sets localStorage, and by the time React mounts, the data is there.

Firefox? Not so much. About 25% of our lifecycle tests were failing with "Loading agreement..." stuck on screen. The page rendered before the init script finished writing to localStorage.

The Diagnosis

Playwright's error context snapshots told the story. On first failure:

- paragraph: Loading agreement...

On retry (with more time):

- heading "Retainer Agreement"
- button "Connect Wallet"  # Auth data missing too!

The page loaded fine on retry, but auth data from localStorage wasn't picked up either. Classic timing issue.

The Fix

We had one navigation helper:

export async function gotoPage(page: Page, url: string) {
  await page.goto(url, { waitUntil: 'commit' });
  await page
    .getByRole('link', { name: /Papre/i })
    .first()
    .waitFor({ state: 'visible', timeout: 30000 });
}

commit returns as soon as the server responds — before scripts execute. Fast for interactive tests, but too fast for Firefox when init scripts need to complete.

We added a second helper:

export async function gotoAgreementPage(page: Page, url: string) {
  await page.goto(url, { waitUntil: 'domcontentloaded' });
  await page
    .getByRole('link', { name: /Papre/i })
    .first()
    .waitFor({ state: 'visible', timeout: 30000 });
}

domcontentloaded waits for the HTML to be fully parsed and all deferred scripts to execute. This gives addInitScript time to complete before React reads localStorage.

The key insight: you can't use domcontentloaded everywhere. Our wizard/create tests use keyboard shortcuts (Ctrl+Shift+D for auto-fill) immediately after navigation. The extra wait from domcontentloaded caused those tests to timeout — the page wasn't interactive fast enough.

So: gotoPage for interactive flows, gotoAgreementPage for data-dependent pages.

Results

Before: 23 Firefox failures out of 240 overnight tests
After: 240/240 pass across Chromium, Firefox, WebKit, Mobile Chrome, Mobile Safari

The Broader Session

Beyond the Firefox fix, we shipped:

8 retainer lifecycle tests (full state machine)
NDA gap tests (one-way variant, terminate action)
Safety-net gap tests (expired deadline enforcement, dispute evidence)
GitHub Actions overnight workflow
3 app bugs found only through E2E coverage

Builder's Note

Spent most of the day thinking about fragmentation — how splitting yourself into roles creates anxiety. The code mirrored that perfectly: scattered tests across directories, inconsistent browser behavior. Consolidation brought clarity to both. Wholeness is ease.

Building Papre — composable agreement infrastructure for trustless coordination.

How We Replaced Hardcoded Legal Templates with Accord TemplateMark: Composable Prose for Smart Contracts

Chris — Mon, 23 Feb 2026 16:02:07 +0000

TL;DR: We migrated 9 agreement types from hardcoded legal templates to Accord Project's TemplateMark system — typed data models, reusable clause packages, and a generic evaluation pipeline. 21 commits across 4 days. Here's the full architecture.

The Problem

Our agreement platform had hardcoded HTML templates for each agreement type. Adding a new type meant copy-pasting a template, manually wiring up field interpolation, and hoping the field names matched the smart contract interface. At 9 types this was already painful. At 100 it would be impossible.

Worse, the legal prose had no typed data model. Field names were strings, validation was ad-hoc, and there was no systematic way to verify that the prose template matched the smart contract's ABI. A typo in a field name wouldn't surface until someone tried to create an agreement on-chain.

We needed composable prose that mirrors our composable on-chain architecture — both layers built from atomic, reusable primitives.

The Approach: Accord Project

Accord Project provides two key technologies:

Concerto — a modeling language for typed data structures
TemplateMark — a templating language that binds Concerto models to legal prose

Each clause becomes a self-contained package with four files:

clauses/{slug}/
  package.json          # Faceted metadata (function, domain, on-chain mapping)
  model/model.cto       # Concerto model (typed fields with decorators)
  text/grammar.tem.md   # TemplateMark prose template
  test/sample.json      # Sample data for testing

Clauses compose into contracts via manifests:

{
  "id": "software-milestone",
  "name": "Software Contractor Milestone Agreement",
  "model": "org.papre.contracts.milestone@1.0.0.SoftwareMilestoneContract",
  "sections": [
    { "heading": "1. Parties", "clause": "parties", "as": "parties" },
    { "heading": "2. Project Overview", "clause": "project-scope", "as": "projectScope" },
    { "heading": "3. Milestones", "clause": "milestone-payment", "as": "milestonePayment" },
    { "heading": "4. Deliverables", "clause": "deliverables", "as": "deliverables" },
    { "heading": "5. IP Assignment", "clause": "ip-assignment", "as": "ipAssignment" }
  ]
}

An assembler reads the manifest, fetches clause templates from the library, and stitches them into a single TemplateMark document wrapped in {{#clause}} blocks.

The On-Chain Bridge

This is where it gets interesting. Concerto models can declare their Solidity parameter mappings directly using custom decorators:

concept MilestonePaymentClause {
  @OnChain("_descriptions,_amounts,_deadlines", "bytes32[],uint256[],uint256[]")
  @Conversion("milestones")
  o MilestoneItem[] milestones

  @OnChain("_paymentToken", "address")
  @Conversion("tokenAddress")
  o PaymentCurrency currency default="ETH"
}

The @OnChain decorator maps a prose-layer field to its Solidity counterpart — name and type. The @Conversion decorator specifies the transformation function. The assembler can extract these to produce an ABI parameter summary:

@OnChain ABI parameters:
  _client : address (from client)
  _contractor : address (from contractor)
  _descriptions : bytes32[] (from milestones)
  _amounts : uint256[] (from milestones)
  _deadlines : uint256[] (from milestones)
  _paymentToken : address (from currency)

This connects the prose layer to the smart contract interface at the model level. When someone fills out the legal template, the system knows exactly how to encode the data for the on-chain call. A mismatch between the prose and the contract is caught at build time, not at transaction time.

The Evaluation Pipeline

The runtime pipeline flows through Redis KV and a VM sandbox:

papre-accord repo → seed-accord.mjs → Redis KV
   → /api/accord/template/[id] → clause stitching → rendered prose
   → /api/accord/evaluate → VM sandbox → ALLOW/DENY/NEEDS_INPUT
   → intent-executor → writeContract()

Seeding: seed-accord.mjs reads clause packages from the papre-accord repo and stores them in Redis KV:

accord:clause:{slug}        → clause grammar, model, facets
accord:metadata:{id}        → template metadata, field manifests
accord:evaluator:{id}       → compiled TypeScript evaluator logic
accord:index                → list of all available templates

Template resolution: The /api/accord/template/[contractId] route fetches clause grammars from KV and stitches them into a single TemplateMark document at request time.

Evaluation: The client sends form data to /api/accord/evaluate, which runs Accord's TypeScript logic in a Node.js VM sandbox. The evaluator returns a GenericActionDecision:

// Three possible outcomes:
{ action: 'ALLOW', message: 'All requirements met' }
{ action: 'DENY', message: 'Missing required field: ...' }
{ action: 'NEEDS_INPUT', message: 'Please provide: ...' }

On ALLOW, the intent-executor encodes the parameters per the @OnChain decorator mappings and calls writeContract().

Accept Strategy Pattern

Each agreement type registers a self-describing strategy that handles the on-chain creation:

interface AcceptStrategy {
  templateId: string;
  singletonAddress: string;
  abi: any[];
  usesEncryption?: boolean;
  usesMultiSignerAcceptance?: boolean;
  createOnChain(params): Promise<`0x${string}`>;
  buildPartyMapping(data): PartyMapping;
}

Strategies self-register at module scope:

// In acceptStrategies.ts
registerAcceptStrategy('software-milestone', {
  templateId: 'software-milestone',
  singletonAddress: MILESTONE_AGREEMENT_ADDRESS,
  abi: MILESTONE_AGREEMENT_ABI,
  usesEncryption: true,
  createOnChain: async (params) => { /* ... */ },
  buildPartyMapping: (data) => { /* ... */ },
});

9 strategies across 3 categories:

5 traditional — dedicated Solidity contracts (freelance, milestone, retainer, safety-net, NDA)
3 Accord — generic factory via createAccordStrategy() (equipment-rental, papreboat-rental, liability-waiver)
1 simple-document — generic on-chain anchor for non-contract templates

Adding a new agreement type is now: write a manifest, register a strategy, seed to KV.

Clause Library Design

The clause library uses faceted classification instead of folder hierarchy. Each clause carries independent metadata facets:

{
  "facets": {
    "function": ["payment", "escrow"],
    "domain": ["software", "freelance", "construction"],
    "onChain": ["MilestoneClause", "EscrowClause"],
    "lifecycle": ["execution"],
    "risk": ["financial"],
    "variables": true
  }
}

A single hierarchy breaks when a clause belongs in multiple categories (an "Escrow with Dispute Resolution" clause would need to go in financial/ or governance/, but not both). Facets solve this — you can search from any direction: "all financial-risk clauses," "all clauses that map to EscrowClause," "all static prose for universal use."

Inspired by DigiKey's parametric component catalog, Ranganathan's Colon Classification, and legal clause banks like SALI and Practical Law.

Results

9 agreement types running through one generic pipeline
0 hardcoded templates remaining
12 reusable clause packages in the library
Adding a new agreement type = manifest + strategy + seed

What Else Shipped This Week

API v1 with public signing — external users can sign agreements without a Papre account
Terms of Service migrated to papre-accord — no more special-case rendering
Ctrl+Shift+D test data for 3 new agreement types (equipment-rental, papreboat-rental, liability-waiver)
Lit Protocol encryption gracefully degrades instead of crashing
Embedded wallet fallback when smart wallet unavailable on Fuji
104 ESLint warnings eliminated, deduplicated hooks across the codebase
16 architecture documents written (7 new, 6 migrated to vault, 3 updated)
CHANGELOG catch-up with 12 missing entries

Builder's Note

Blockchain development, running group therapy, managing staff and clients, and personal meditation and yoga practice create an ever-changing, ever-shifting flow. All I can do is relax into it and let it pass through me. If I clench, the current catches me and throws me around. If I stay present but relaxed, the flow leaves nothing behind except the invigoration of energy in motion and the bliss of exploration.

Stress and anxiety in me are reactions, not to external circumstances, but to my own clenching against those circumstances. In private work with others, I often hear a familiar fear: if they meditate too much, they'll lose their edge. They'll lose their drive to succeed.

Maybe. And if you do, it's only because you've shifted out of the energy flow your biology, your family, your society, your experience have imposed upon you. By relaxing, you stop doing their bidding. You enter a more natural flow, where life is, frankly, easier. But releasing the NEED to achieve isn't universal in those who meditate, or in those who go deep within themselves to discover.

Others—like me—dig deep and find that the natural course is to attempt to make big changes in reality, to bring lots of energy to bear on the material world.

That's the thing about deep internal work: you don't get to choose where it heads ahead of time. I should say, your ego doesn't get to choose ahead of time. In my life, I've come to feel like there's a kind of higher-self calling the shots. I've come to experience this higher-order autonomy, not as an idea, but as something alive in me.

When I let go of the need to control, what I thought I wanted and needed usually falls away, and something far better manifests itself. This has happened over and over and over. My wife is 10x the woman I was seeking. My project is 1000x as incredible as I envisioned. My life is indescribably better than anything I imagined, even at my most optimistic. And it sure as hell is an improvement over the version of me that would have been satisfied with not dying totally broken and alone.

Sometimes it feels like I've died, and that God—if there is one—is so merciful that it shifted me to heaven. And in order to keep me from freaking out, that heaven looks a lot like the world I left at death.

What Running a Sober Living Facility Taught Me About Building a Web3 Startup

Chris — Fri, 20 Feb 2026 01:38:39 +0000

TL;DR: Sometimes the best day for your project is the one where you don't write any code.

The Two Lives

I direct a men's sober living facility by day. I build composable agreement infrastructure on Avalanche by night. These two jobs could not be more different — and yet they're teaching me the same lesson.

The Consensus Trap

I've always managed by consensus. I like alignment. I like people feeling heard. I like building something that feels like ours, not mine.

When the team is mature and motivated, consensus is a force multiplier. But it has a cost:

It slows decisions. Every voice needs to be heard before moving.
It blurs accountability. When the outcome belongs to "everyone," no one owns it.
It becomes a veto system. One hesitant voice can stall the move that matters most.

In sober living, I can't afford that. When someone violates probation terms, when an employee isn't performing, when 26 men are counting on the structure I provide — decisions have to land.

Applying It to Papre

Papre needs the same clarity. As I scale from solo builder to team:

// The old pattern
function decide(proposal) {
  const votes = await pollEveryone(proposal);
  if (votes.some(v => v === 'no')) return STALL;
  return MOVE;
}

// The new pattern
function decide(proposal) {
  const input = await gatherPerspectives(proposal);
  const decision = evaluate(input, vision);
  communicate(decision, reasoning);
  return MOVE;
}

Collaboration without drift. Input without paralysis. Culture without confusion.

The Compound Effect

If each job induces 100 units of growth, the total isn't 200. It's in the thousands. The skills compound because they're exercised in completely different contexts.

Yesterday I shipped an Accord evaluator integration — 56 tests, dual-path execution, feature-flagged rollout. But today's leadership reflection will outlast any commit.

Builder's Note: I dream about where Agreement technology can take humanity over the next 250, or even 1000 years, and then I reverse engineer that future by creating today's code. Some days that means writing TypeScript. Some days it means learning to hold the line.

Building Papre — composable agreement infrastructure for trustless coordination.

How AI Changed the Way I Build (Not Just the Speed): A Solo Founder's Reflection

Chris — Tue, 17 Feb 2026 22:34:33 +0000

TL;DR: I spent years thinking I had executive dysfunction. AI didn't cure anything — it just matched my cognitive throughput, which turned out to be the actual bottleneck.

The Problem

I've struggled with executive function all my life. The kind that doesn't respond to self-help books, willpower, or any of the countless interventions I tried.

Before AI, I was at my best when working on five unrelated projects simultaneously. More context-switching, paradoxically, meant more output. My brain needed the throughput.

The Shift

With modern AI, I can devote all my time to one project — Papre, composable agreement infrastructure for trustless coordination on Ethereum. Instead of trying to type 1,000 words a minute to keep up with my thoughts, I break the work into well-defined pieces and delegate.

The workflow looks like this:

Thinking → Breaking into pieces → AI implements → I review/redirect → Ship

Instead of:

Thinking → Typing frantically → Context lost → Start over → Burn out

What I'm Building

Papre is composable agreement infrastructure. Think of it as microservices for legal contracts — atomic clauses that compose into agreements, both on-chain (Solidity) and off-chain (TypeScript).

I'm a transactional lawyer, CS/math grad, and meditation teacher. That unique combination is exactly what this project needs. AI didn't replace any of those skills. It just let me use them all at once without the friction.

The Takeaway

If you've struggled with executive function and found that AI changed your work life — I'd argue it's not that AI fixed you. It's that the tooling finally matched your cognitive throughput.

The dysfunction was never in the brain. It was in the gap between thinking and building.

Builder's Note: Day 5 of building Papre. 12-14 hour days, hyperfocused. The throughput is the therapy.

How We Replaced a 310-Line Translation Layer with Native TemplateMark Parsing

Chris — Tue, 17 Feb 2026 21:44:23 +0000

TL;DR: We deleted 310 lines of template middleware by switching to native Accord Project TemplateMark grammar. Zero regressions.

The Problem

Our legal agreement templates needed to render in the browser. We had a translation layer converting TemplateMark grammar into an intermediate format — 310 lines of middleware that existed for no good reason.

The Approach

TemplateMark already has a formal grammar. We were translating to an intermediate format unnecessarily.

// Before: translate TemplateMark -> intermediate -> render
const intermediate = translateTemplate(templateMark);
const html = renderIntermediate(intermediate);

// After: render TemplateMark directly
const html = renderTemplateMark(templateMark);

Result

310 lines deleted
Zero regressions across 6 agreement types
Simpler mental model for contributors

Builder's Note

Spent most of the day convinced the tests would break. They didn't. Sometimes the best code you write is the code you delete.