Jonas Vanderhaegen jonasvanderhaegen

MCP: the complete option surface

Research notes (June 2026). Everything an MCP implementation can offer, on both sides of the wire: the primitives, the utilities, the transports, authorization, and where the protocol is heading (the 2026-07-28 release candidate changes the picture substantially). Companion to the deep-dive notes on resources, prompts, and the LSP comparison.

Spec versions to date: 2024-11-05, 2025-03-26 (Streamable HTTP, OAuth), 2025-06-18 (elicitation, structured tool output, resource indicators), 2025-11-25 (current

Designing Advanced Release-Management Flows

A Reusable Prompt for LLM-Assisted System Design

1. How to use this prompt

Paste Section 9 ("The prompt") into any capable LLM and replace the bracketed parameters with your application's domain, platform constraints, and team conventions. The remaining sections are reference material: read them before customising the prompt so you understand the concepts being referenced. The models below are derived from Google Play Console and App Store Connect; they generalise to any system where an artifact must pass through composition, validation, review, and staged deployment.

The method: how this project gets built, and an evaluation of it

Notes on an operator's working style, extracted from the skyline sessions (benchmarks, five shipped features, a release, an LSP client, six research gists, a blind re-test). Written as raw material for a .sky workflow that reproduces the loop: dig deep and research first, ship, then prove it worked.

1. The prompting style, observed

The prompts are short, lowercase, typo-tolerant, and high-trust: "go", "make it

The period: 2026-05-29 → 06-03, read back from the sessions

This is my read of six days of Claude Code sessions (Friday May 29 through June 3, 2026), written against "The method", which was extracted from a single arc on the final day. The question: does the week match the doc, and where doesn't it.

Method for this doc: five parallel analysis agents read the prompt timelines and transcripts per project area (the code-graph indexer, the Go daemon and binaries, the web monorepo, the workflow library, misc), cross-checked against git logs, release tags, and the gist trail. Numbers below are measured, not estimated, unless marked.

1. What the corpus actually is

Numbers first, because they reframe the whole question:

Agent org — operator entry point and flow diagrams (2026-06-10)

Entry point — how the operator gets the ball rolling

Open soloterm and select (or create) the project.
Spawn the ORCHESTRATOR as a Solo agent: agent tool "Claude" (claude --dangerously-skip-permissions), name it orchestrator, switch it to Opus (/model opus or spawn arg). It MUST be a Solo-managed process — wake timers deliver into its PTY; a plain terminal session cannot be woken.
Type one message into its PTY: You are the conductor. Mission: <goal, constraints, repos>. The /orchestrator skill auto-invokes: it anchors the board, plans lanes into todos, spawns Codex workers full-auto, arms idle-wakes, and goes quiet.
From then on the operator touches three surfaces only:
- QUESTIONS pad (+ one notification per blocking item) — decisions the org needs from you;

the todo board — live status, milestone comments, verdicts;

Board alignment addendum (2026-07-06)

This file records how the vision in strategy-vision.md maps onto the live GitHub board after the 2026-07-05 program restructure (epic #37), and what changed on 2026-07-06. The vision doc itself is unchanged; treat this as its tracking companion.

Status since the vision doc was written

Live foundation VALIDATED during market hours (2026-07-06): quotes, trades, 1m bars flowing and persisted with real timestamps (#23 market-hours pass; fixes #75, #77, #79).
Recorder professionalization program filed AND half-executed the same day (epic #80): internal bars merged (#64, closes #49), per-symbol quote/Greeks sampling + candle upsert + TimescaleDB compression merged (#88). Remaining lanes: policy doc #81, sampling cutovers, dynamic scanner universe #83, live Greeks #86.
DAG engine foundation merged: schema + canonical definition_hash (E-01), static validator (E-02 groundwork), op registry + indicator allowlist (E-03), versioned storage with migration 0007 (E-04).

Infisical self-hosted backend: taming idle RAM (600–800 MB)

The self-hosted Infisical backend (infisical/infisical) sits at 600–800 MB RSS even when idle. On a small/single-user box it's often the single fattest process on the machine. Here's the diagnosis, plus an honest account of what actually controls it and what doesn't.

Symptom

$ docker stats --no-stream infisical-backend

MCP, LSP, custom protocols, and local models — a mental model

A short, diagram-first explainer untangling four things people routinely conflate: MCP, LSP, rolling your own agent↔tool protocol, and whether a model "knows" MCP.

	use std::env;
	use std::path::{Path, PathBuf};

	fn link_mode() -> &'static str {
	if env::var("LBUG_SHARED").is_ok() {
	"dylib"
	} else {
	"static"
	}
	}


	## Advisor

	Call advisor() BEFORE substantive work: before writing, before committing to an approach. Reading files to orient is fine first.

	Also call when stuck (errors recurring, approach not converging), when changing approach, or when the task is complete, though first make deliverables durable (write file, commit).

	Skip when you are already running as Opus, since advisor() would be Opus consulting itself, or when this turn immediately follows a completed /plan session, since the plan output already serves as the advisor input.

	On longer tasks: once before committing to approach, once before declaring done. Don't call after every step: advisor adds most value before the approach crystallizes.