Fix Untitled titles: convert all YAML frontmatter to org-style headers
This commit is contained in:
Hermes
@@ -3,6 +3,7 @@
|
||||
:CREATED: [2026-05-11 Mon]
|
||||
:ID: 7e575c8d-aa28-4588-bfa1-5f6144165a13
|
||||
:END:
|
||||
#+title: Engineering Infrastructure
|
||||
* Engineering Infrastructure
|
||||
|
||||
- [[file:the-repl-as-cognitive-substrate.org][The REPL as Cognitive Substrate]] — A REPL — Read, Eval, Print, Loop — is an interactive programming environment tha
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Definite Description Resolution
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Definite Description Resolution
|
||||
:PROPERTIES:
|
||||
:ID: 3f4573b2-aa55-44a7-a6c8-861dc443ac32
|
||||
:ID: design-description-resolution
|
||||
:CREATED: [2026-05-14 Thu]
|
||||
:WEIGHT: 40
|
||||
:CREATED: [2026-06-04 Thu]
|
||||
:END:
|
||||
#+title: Definite Description Resolution
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
When the user says "the function that validates secrets," the agent must resolve this to a specific code entity. Natural language is ambiguous — there might be multiple functions matching the description. Resolving to the wrong one causes incorrect actions.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Literate Programming as Discipline
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Literate Programming as Discipline
|
||||
:PROPERTIES:
|
||||
:ID: e6269aec-ea0a-406e-8b44-9dbd7b38c83a
|
||||
:ID: design-literate-programming
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
:CREATED: [2026-06-04 Thu]
|
||||
:END:
|
||||
#+title: Literate Programming as Discipline
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
The decision to use Org-mode as the source of truth for code, not just documentation, is not a ceremonial preference. It is a constraint mechanism that enforces better engineering habits at the cost of convenience.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Local-First Architecture
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Local-First Architecture
|
||||
:PROPERTIES:
|
||||
:ID: 3747ae5f-b4e5-4503-b397-a5b07862062d
|
||||
:ID: design-local-first
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
:CREATED: [2026-06-04 Thu]
|
||||
:END:
|
||||
#+title: Local-First Architecture
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
Passepartout is designed to run on the user's machine, on their hardware, with their data, without requiring an internet connection. This is not a deployment option — it is an architectural commitment. The system must be able to reason, plan, and act using only the resources available locally.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Observability and the Thought Trace
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Observability and the Thought Trace
|
||||
:PROPERTIES:
|
||||
:ID: ee527687-28e2-4f0f-8d3c-af5cc531e3d4
|
||||
:ID: design-observability
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
:CREATED: [2026-06-04 Thu]
|
||||
:END:
|
||||
#+title: Observability and the Thought Trace
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
When a human asks why the system made a decision, the answer must be findable. In most AI systems, the reasoning is ephemeral — it exists in the model's activations and disappears when the session ends. In Passepartout, every significant cognitive event is written to an Org buffer as it happens.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Cybernetic Loop: Why the Metabolic Pipeline Works
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Cybernetic Loop: Why the Metabolic Pipeline Works
|
||||
:PROPERTIES:
|
||||
:ID: bf3f84da-358b-4d87-bc1a-fa91d1994e20
|
||||
:ID: design-cybernetic-loop
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
:CREATED: [2026-06-04 Thu]
|
||||
:END:
|
||||
#+title: The Cybernetic Loop: Why the Metabolic Pipeline Works
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
The Perceive → Reason → Act cycle is not a software architecture pattern. It is a cybernetic feedback loop — the mechanism by which a system steers itself toward a goal in a changing environment.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The Evaluation Harness
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The Evaluation Harness
|
||||
:PROPERTIES:
|
||||
:ID: a6dd0808-4366-4bda-be6e-f6d43f2eeab8
|
||||
:ID: design-evaluation-harness
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
:CREATED: [2026-06-04 Thu]
|
||||
:END:
|
||||
#+title: The Evaluation Harness
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
SOTA parity is meaningless without measurement. A system that claims to match commercial agents must demonstrate it through reproducible benchmarks, not through feature checklists. The evaluation harness is the apparatus by which Passepartout proves its capabilities.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The MCP Strategy
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The MCP Strategy
|
||||
:PROPERTIES:
|
||||
:ID: bffb1695-5bf5-4434-8f64-e74f19d2e537
|
||||
:ID: design-mcp-strategy
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
:CREATED: [2026-06-04 Thu]
|
||||
:END:
|
||||
#+title: The MCP Strategy
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
The Model Context Protocol (MCP) is a standard for connecting AI systems to external tools and data sources. It defines how a client requests tools from a server, how the server exposes its capabilities, and how the client invokes them. The ecosystem is growing: MCP servers exist for GitHub, Slack, Postgres, filesystem access, and much more.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: The REPL as Cognitive Substrate
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* The REPL as Cognitive Substrate
|
||||
:PROPERTIES:
|
||||
:ID: 1ede13cb-05c0-4b1a-a873-98cf89bade81
|
||||
:ID: design-repl-cognition
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
:CREATED: [2026-06-04 Thu]
|
||||
:END:
|
||||
#+title: The REPL as Cognitive Substrate
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
A REPL — Read, Eval, Print, Loop — is an interactive programming environment that reads an expression, evaluates it, prints the result, and loops back to read the next expression. It is the opposite of batch processing: where batch compiles and runs a program in one shot, a REPL works one expression at a time, with each evaluation building on all previous ones. The state accumulates. The session is the program.
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Time Awareness as a Structural Advantage
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Time Awareness as a Structural Advantage
|
||||
:PROPERTIES:
|
||||
:ID: 9e9950a8-82a5-42db-af2d-742ba09ff8ed
|
||||
:ID: design-time-awareness
|
||||
:CREATED: [2026-05-07 Thu]
|
||||
:WEIGHT: 40
|
||||
:CREATED: [2026-06-04 Thu]
|
||||
:END:
|
||||
#+title: Time Awareness as a Structural Advantage
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
Passepartout's architecture provides three layers of time awareness, each enabled by infrastructure that competitors lack:
|
||||
|
||||
|
||||
@@ -1,16 +1,8 @@
|
||||
---
|
||||
title: Token Economics and Performance Advantage
|
||||
type: reference
|
||||
tags: :passepartout:architecture:
|
||||
---
|
||||
|
||||
* Token Economics and Performance Advantage
|
||||
:PROPERTIES:
|
||||
:ID: 876fe3af-80fb-42dc-a0d0-714670e5b964
|
||||
:ID: design-token-economics
|
||||
:CREATED: [2026-05-07 Wed]
|
||||
:WEIGHT: 40
|
||||
:CREATED: [2026-06-04 Thu]
|
||||
:END:
|
||||
#+title: Token Economics and Performance Advantage
|
||||
#+filetags: :passepartout:architecture:
|
||||
|
||||
This section analyzes how Passepartout's architectural decisions translate into token usage, latency, and cost versus competing agent designs.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user