DEV Community: Jean-Sebastien Beaulieu

At What Scale Does a Storm Start Making Sense?

Jean-Sebastien Beaulieu — Mon, 21 Sep 2026 13:12:49 +0000

A light switch is partly responsible for why I am now reading about meteorological satellites.

During my training in heavy-equipment mechanics, electricity and hydraulics changed what I saw in an ordinary action. Pressing a switch became an invitation to follow the circuit. Something happened somewhere else because a whole arrangement of relationships allowed it to happen.

I have been troublesome around simple explanations ever since.

That curiosity followed me into software, then mathematics, two books, educational tools, and a growing collection of questions about how humans and AI can investigate something together. Over the last few days, it has found a particularly unreasonable object to become interested in: the atmosphere.

Reasonable opening task: understand one observation. Long-term ambition: contribute useful mathematics to meteorological satellites. My brain apparently sees these as neighbouring items on a checklist.

I have just published Math Dev Journal 01: Reading the Living Atmosphere / Leer la atmósfera viva. The full English and Spanish editions are here:
DOI: 10.5281/zenodo.22848503.

There is also a short companion podcast.

This post opens the notebook behind it. Bring your curiosity. I have already supplied the excessive number of questions. The question I keep returning to is this:

at what scale does a storm start making sense?

I can look at a cyclone and recognize its organization. Then my attention starts moving inward. A spiral. A boundary. A smaller disturbance. Something developing inside something larger. I want to know which relationships survive as I change the scale, and which ones I lose by looking too closely.

My first instinct is to zoom in. The mathematics asks me to be more specific.

There is the scale of the picture on my screen. There is the spatial support of the data behind it. And there is the scale over which I calculate something. A beautifully detailed coastline can sit underneath a much coarser atmospheric field. The coastline belongs to the map; the weather information retains its own resolution. The mouse wheel has considerable authority over the picture and remarkably little authority over the atmosphere.

That distinction is already shaping the observatory I want to build. When I change the view, I want to see what changed in the calculation, what stayed fixed in the measurements, and what the display merely interpolated. It would make the interface an instrument for asking better questions.

Here is a small mathematical example from the paper that captures why I enjoy this work. Imagine two equal-area cells and two equally likely rainfall scenarios. These are invented numbers for an exact example:

Scenario	Cell A	Cell B	Regional average
1	0 mm	20 mm	10 mm
2	20 mm	0 mm	10 mm

For either cell, the 95th percentile of this two-outcome probability distribution is 20 mm. Average those two local percentiles and you get 20 mm. But the regional average is 10 mm in every scenario. Its 95th percentile is therefore 10 mm.

Same starting numbers. Different order of operations. A different answer to a different question.

The relationship between the cells carries information. If I summarize each location separately and then combine the summaries, I can lose that relationship. For a regional statistic, I need to calculate the regional value within each coherent scenario first, then summarize those results. This is the kind of mathematics that makes me sit up. Two rows are enough to expose a mistake that could hide comfortably inside a very impressive dashboard.

My books, Fractal NeutroGeometry and Mapping the Invisible Infinite, brought me toward questions about structure, indeterminacy, and representation. Now I want to give those questions something concrete to push against. If I propose a descriptor of a cloud boundary, I need to specify the boundary, the preprocessing, the range of scales, and what useful information the descriptor might add.

I also want to examine support, unresolved information, and contrary evidence separately. That is where neutrosophic representations interest me. Plithogenic methods raise further questions about relationships among attributes. Their practical value here will depend on comparisons with simpler ways of organizing the same evidence.

I can be attached to a question and still let an experiment change my mind about the method. After investing years in an idea, that takes a little practice. I am getting some.

My recent agent-development training has been unexpectedly useful in getting here. I spent time separating roles, tools, sessions, persistent memory, and the context an agent receives for one task. I kept applying the lessons to educational companions and to the practical problem of returning to work after a handoff.

I know that problem rather personally. Switching tools or models can leave me reconstructing decisions I already spent energy making. Somewhere in the conversation, an important qualification disappears. I remember that we resolved it. Finding exactly what we resolved becomes the next job. For an atmospheric investigation, that missing qualification could be the forecast cycle, a unit, the source snapshot, or which time was actually available when a prediction was made.

That gives my Context Continuity Protocol, CCP, a precise job to investigate: carry enough of the scientific task across a handoff that the next human or agent can continue faithfully. Keep the question, the relevant data references, the transformations already applied, the uncertainties, and the next action together.

In the proposed observatory, one agent might retrieve records, another invoke a numerical tool, and another review inconsistencies. Each would receive tools suited to that responsibility. Selected application actions could be exposed through WebMCP, alongside the human controls. The calculation should retain the same meaning whichever route invokes it.

I want that same continuity for a learner using an educational side panel. Coming back tomorrow should mean recovering the question and the understanding we were building. Remembering a transcript is only part of that experience.

The forecasting foundation I am studying is WeatherNext. My proposed contribution sits around existing forecasting work: organizing a particular investigation, checking transformations, testing a mathematical addition, and making the result understandable.

The next experiment I want to prepare is deliberately small: one historical cyclone, one defined target, an identified forecast and observation record, an unchanged reference, and one candidate addition. If the extra mathematics helps, I want to be able to explain where. If it fails, I want a result precise enough to teach me something.

That work still lies ahead. What I have completed is the first bilingual entry in this journal: nine chapters, eleven equations, and a registry of sixty-two external sources. It gives the investigation a starting point that another person can inspect and challenge.

And now the satellites are asking for homework.

For example, the GOES-R series' Advanced Baseline Imager observes in sixteen spectral bands spanning visible, near-infrared, and infrared wavelengths. Choosing a band already changes the question I can ask of the image. I want to understand what the instrument measures, how a useful product is derived from it, and how time, resolution, and uncertainty enter the interpretation.

My first exercise could be as simple as following one event through one documented channel, then explaining each step from observation to displayed result. I would like to earn the next layer of complexity by understanding the previous one.

Eventually, I want to explore whether a small, bounded analytical function could be useful aboard an instrument: a quality check, a feature-selection step, or a compact report prepared for transmission. That brings execution time, memory, energy, and recovery into the mathematics. Flight integration would require its own engineering and qualification with the relevant specialists.

I find that prospect exciting because it gives a mathematical idea a demanding destination. Somewhere between an equation and an instrument, every convenient assumption has to meet the world.

Héctor Fernando Aguilar also has room to change the direction. The planned second journal entry is for his perspective, in his own voice. The third will take the shared question toward implementation. These entries are part of the longer path toward Book III, with space for results that surprise us and revisions that improve the question.

The NASA Space Apps Challenge, scheduled for November 14–15, 2026, is the first public milestone I am aiming toward. Hackathons have a useful effect on me: they make an expanding idea meet another person's time and attention. Eventually, someone has to be able to open the thing and understand what it does.

For this direction, I would like that encounter to be simple. Choose a region, inspect the available evidence, follow one calculation, and see what the result supports. A person arriving fresh should be able to ask a difficult question and find the relevant source. That would give the mathematics, the interface, and the agent workflow a shared purpose.

For the entry itself, I will select an official challenge and follow its build window and reuse rules. This journal is the research preparation. The exact submission still has to earn its scope. What attracts me is the chance to meet people who know different parts of the problem and build something useful together. A good hackathon can turn a private obsession into a conversation with working parts.

That is what I want this journal to feel like: the pleasure of learning something difficult with enough care that somebody else can pick it up, question it, and take it further. I come to this as a builder who loves mathematics and still enjoys the moment when an ordinary thing opens into a whole system.

A switch did it once. A satellite image might do it again.

I would love to hear from people who have already made a few mistakes in this territory:

If you were teaching a developer to read satellite data, which instrument, channel, and historical event would you start with—and what misunderstanding would you tackle first?
Have you ever changed the scale or order of a calculation and watched a convincing result fall apart? I would enjoy hearing the actual example, especially the small one that taught you a large lesson.
When research passes between humans, tools, or AI agents, what is the one piece of context you insist must survive? I am particularly interested in something you learned to preserve after losing it once.

The Day I Needed a HUMAN.md for My Agentic Workflow

Jean-Sebastien Beaulieu — Fri, 11 Sep 2026 04:13:13 +0000

I did not write this article from a clean desk, a calm roadmap, or a perfect technical plan.

I wrote it after a day where I had to stop, breathe, and admit that my own system had become too hard for me to live inside. I was training on Google Skills, watching IBM explain quantum hardware, organizing case studies, producing final PDFs, reserving a DOI, fighting token limits, and trying to understand why a tool that should accelerate me could also make me feel completely disorganized.

The article is attached to a reserved Zenodo DOI:

DOI: 10.5281/zenodo.22699683

The idea of HUMAN.md is not presented as a universal technical rule. It is an analogy that forced me to think clearly.

We already write AGENTS.md files so models know how to behave in a repository. But what happens when the whole computer becomes organized for agents, traces, guardrails, memories, plugins, logs, handoffs, and automation — while the human who started the work can no longer find a simple path back into it?

That was the uncomfortable question.

At 6:30 p.m., I stopped the training because I needed a retrospective more than another task. I had been pushing all day, but pushing is not always progress. Sometimes the most productive act is to name the friction before it eats the rest of the week.

The friction was not abstract. It had a cost. I had burned through token budget trying to build educational software and ended up with results that did not match the effort, the money, or the emotional weight behind the project. That hurt because the goal was not vanity. The goal was to build something useful for children, for learning, for SecuredMe, for a future where my work can finally stand on its own.

That is where ego entered the article.

When a model changes the field overnight, it is easy to feel robbed of an edge. It is easy to think: if everyone can now access the same capability, what makes my years of work matter? But that question can become a trap. If I stay there, I abandon the reason I started. Research was never supposed to be only about being first. It was supposed to be about opening doors.

So the article became a refusal to quit.

I do not want to complain that the world changed. I want to understand the change fast enough to move with it. I want to take the pain, remove the ego where it blocks me, keep the pride where it gives me strength, and transform the mess into a better operating system.

The Google training helped more than I expected because it made the lesson simple: be concise, be specific, ask one thing at a time, use examples, and reduce unsafe open generation when classification is enough. That is prompt design, yes, but it is also life design for working with AI. My own prompts, my own folders, and my own architecture were carrying too many tasks at once.

The IBM Quantum webinar gave me another mirror. A quantum computer is not just qubits. It is topology, couplers, noise, packaging, verification, and practical limits. An AI workflow is the same. The model is not the whole system. The environment around it decides whether the work becomes clear or painful.

That is why HUMAN.md became useful as an image in my head.

It means: before another agent reads the project, make sure I can read it too. Before another automation writes a trace, make sure the next human action is visible. Before spending more tokens, identify the real next decision. Before blaming the model, inspect the architecture I built around it.

It also means protecting the human from the emotional fog of public development. When every message can be AI-written, every offer can be unclear, every collaborator can be real or extractive, trust becomes work. The article does not solve that. It names it. And naming it gives me back some control.

The positive turn is this: maybe nothing was lost. Maybe the old advantage was only the first layer. If the machine can now do more, then my next job is to specialize, clarify my voice, build verifiable public work, and turn what I learned into something people can trust and pay for.

That is the direction I want to keep.

Not abandonment.

Not panic.

Not pretending the pain is not there.

A method.

A readable system.

A human layer inside the machine.

The full bilingual article includes the French and English editions, the references, the visual package, and the disclosure that Codex and Synthia were used as research and refinement partners under my human authorship.

Read the reserved DOI record here:

https://doi.org/10.5281/zenodo.22699683

Knowing When to Stop: The WebMCP Lesson My Side Panels Needed

Jean-Sebastien Beaulieu — Mon, 07 Sep 2026 23:21:14 +0000

Companion short podcast

For almost a month, my education repositories slowed down.

Not because I had lost interest. The opposite was true. I had built so much that I could keep adding features without knowing whether I was improving the experience.

AlgoQuest had Hero Books. Algorithm Builder could forge artifacts. Qbit could accompany a mission. Scholarium was becoming the meeting place for the suite.

But a child would not arrive with five years of SecuredMe context already in mind. They would open a mission, enter a workshop, ask an agent for help, close the laptop, and return later.

At that exact moment, who remembers what they chose? Which tool owns progression? How does the child distinguish a suggestion from a decision?

Git records commits. It does not record the moment an architect looks at his own system and admits: I may be too close to see what is missing.

So I stopped building inside the suite long enough to learn somewhere else.

WebMCP made the button honest

The WebMCP hackathon became my first laboratory.

I went there thinking about side panels. I came back thinking about authority.

A side panel is the visible room beside the work. WebMCP asks the harder question: what named tool exists behind the button, what it accepts, what it returns, and where its power ends.

For a human, a button labelled "Continue" may feel obvious. For an agent, it is incomplete.

Continue which mission? From which revision? Is the action reading, staging, or executing? Who approves it?

That changed my design vocabulary. I stopped asking only, "Can the companion call the function?" and started asking, "Can the system explain the authority, evidence, change, and return path?"

WebMCP is still experimental, but the lesson is already practical: an agentic interface begins with clear promises around each action.

Thanks2Go made the boundary real

The DEV Weekend Challenge became my second laboratory.

With Thanks2Go, I wanted something small: a voluntary two-dollar gesture of gratitude. Not a payment platform. Just a way to say: your help mattered.

The mechanism had to remain smaller than the gesture.

Intent is not approval. Approval is not provider acceptance. A cryptographic signature is not confirmed settlement.

So Thanks2Go used visible states. The agent could inspect and prepare. The irreversible crossing remained a visible human act.

Then another consenting person used the live PayPal path. Two dollars were sent. The transaction completed. I received 1.64 USD after fees.

That was small. It was also complete.

It did not validate every failure path. It did not turn Thanks2Go into a financial product. It proved exactly one live success path.

That discipline returned with me to the Hero Books.

A specialist suggestion is not the child's decision. A returned artifact is not admitted evidence. A replayed request must not advance the same mission twice.

The companion is not a tool menu

Before this pause, I thought of the companion mainly as quick access to tools.

That definition no longer works.

For a Hero Book, the panel must become a living logbook: hero, world, mission, step, talents, inventory, decisions, dice, evidence, tokens, and active specialist.

This is not decoration. It is where a child recovers the continuity of an adventure.

That continuity cannot depend on a panel staying open. Manifest V3 service workers are ephemeral. A memory variable can vanish. A laptop can close at the wrong moment.

So I defined HeroBookPanelState.v1 as explicit, versioned, and revision-aware. The cockpit can reopen the experience, but it does not own progression. AlgoQuest remains canonical.

Algorithm Builder is the forge. Qbit carries continuity. Codex or Gemini can help as specialists.

AlgoQuest keeps the story.

The specialist returns a proposal or receipt. AlgoQuest decides what enters the mission.

The pause became the architecture

I also learned not to outsource proof to a grade.

webmcp.com's evaluation helped me. It found weaknesses and gave direction. But a third-party score measures its own methodology.

So I built a local Evidence Gate in Scholarium. It checks names, schemas, modes, handlers, permissions, refusals, receipts, and agent journeys.

That proves what its own code can inspect.

Only that.

To know whether the cockpit helps a child find their way, I still need real evaluation with children, parents, educators, and accessibility users.

The companions are not finished. Builder still needs to feel like a forge. AlgoQuest needs the rhythm of a gamebook. Qbit needs presence.

But the work is no longer vague.

The engine can read without changing, stage without claiming execution, wait for approval, reject a stale revision, issue a receipt, and return authority.

These behaviors are less spectacular than an avatar or a 3D scene. They are what future surfaces can rest on.

We spend enormous effort teaching AI when to stop. Before payment, publication, or canonical mutation, we ask for confirmation.

The human architect needs the same discipline.

Nobody returns HUMAN_ARCHITECT_APPROVAL_REQUIRED for me.

I must recognize the signal.

I do not want the largest possible number of agentic tools. I want a child moving from AlgoQuest to Builder and then to a specialist to recover their hero, mission, decisions, creations, and earned evidence.

Eventually, I want the companion to help the child need the companion less.

Knowing how to move forward is a skill.

Knowing where to stop is another.

Explore

WebMCP proposal: https://github.com/webmachinelearning/webmcp
Chrome WebMCP docs: https://developer.chrome.com/docs/ai/webmcp
PayPal idempotency: https://developer.paypal.com/reference/guidelines/idempotency/

Thanks2Go: Building a Human-Approved Gratitude Rail in One Weekend

Jean-Sebastien Beaulieu — Sat, 05 Sep 2026 17:47:55 +0000

I used Codex to its fullest potential as a research partner—for code mapping, source comparison, evidence organization, consistency checks, editorial control, and deliverable preparation. I formulated the intent, defined the scope, interpreted the results, arbitrated the conclusions, and preserved every public decision. This collaboration expands my investigative capacity; judgment, responsibility, authorship, and final signature remain under my authority.

This is a submission for Weekend Challenge: Generosity Edition.

What I Built

For five years, I have spent so many hours coding, studying mathematics, debugging, and learning new systems that much of it became ordinary to me. Opening VS Code, reading an unfamiliar repository, shaping an API contract, or asking what must never be automated feels like daily routine.

This weekend changed the scale of that routine.

Two developers asked me for help at almost the same moment that DEV announced its Generosity Edition challenge. One conversation was about learning. The other was about seeing a public portfolio with fresh eyes. I suddenly understood that the knowledge I had stopped noticing could shorten someone else’s path.

Thanks2Go grew from that realization: gratitude should be easy to express, but never easy to automate past the human who is spending it.

The product in one sentence

A creator voluntarily declares one canonical Thanks2Go profile on a page they control, and a visitor can open that profile after an explicit extension click to choose either a fixed PayPal gratitude tip or a Solana devnet demonstration.

There is no account system, feed, ranking, directory, background scan, or payment database. The first profile is my own SecuredMe profile, because a weekend experiment is not a reason to make other people part of a payment system without a separate onboarding and consent process.

Demo

Live profile: thanks2go.securedme.ca/p/securedme
Video: final selection and public embed pending.

The demo begins with a contribution that helped someone move forward. It then shows the declared profile, the click-scoped extension, the fixed 2 USD PayPal handoff, the Solana devnet gesture, a real A2A recipient check, the four WebMCP tools, and a signed receipt verification. Every provider action remains visible and human-controlled.

The live page is usable now. The video link will be added only after its recording excludes payer identity, merchant details, wallet secrets, environment values, and private financial links.

Code

SeCuReDmE-main-dev / thanks2go

Human-approved gratitude rails with Solana devnet, PayPal, A2A, WebMCP, and verifiable receipts

Thanks2Go

Thanks2Go is a human-approved gratitude rail built for the DEV Weekend Challenge: Generosity Edition. A creator declares one canonical profile. A visitor explicitly chooses either a fixed 2.00 USD PayPal gratitude tip or a clearly labelled Solana devnet demonstration.

Agents may inspect, stage, hand off, and verify. They cannot approve, capture, or sign payment.

What is in the repository

React + TypeScript + Vite public profile
Chrome Manifest V3 extension with only activeTab and scripting
Express/Vercel API with signed ten-minute mandates
PayPal Orders v2 create/capture boundary with fixed server-side amount
Solana Commerce Kit 0.1.1 in tip mode on devnet
Two real A2A 1.0 agents using @a2a-js/sdk 1.1.0
ES256 vc+jwt gratitude receipts and public JWKS
Experimental document.modelContext WebMCP progressive enhancement
Contract, API, privacy, permission, and authority-boundary tests

Start locally

Requirements: Node.js 20 or newer and npm 11.

npm ci
copy .env.example .env.local
npm run dev

Open http://localhost:5173/p/securedme. Without…

View on GitHub

The public MIT repository contains the React/Vite page, the Manifest V3 extension, shared Zod contracts, A2A agents, the Express/Vercel API, security documentation, 103 automated tests, and the evidence checklist. The repository was created inside the challenge window. The current release gate keeps the remaining provider and recording evidence visibly pending.

How I Built It

The declaration is small on purpose

<link rel="thanks2go" href="https://thanks2go.securedme.ca/p/securedme">
<meta name="thanks2go:profile"
      content="https://thanks2go.securedme.ca/p/securedme">

The Chrome Manifest V3 extension has only activeTab and scripting. It reads those two selectors and the visible origin only after I click the extension. A conflict fails closed. A missing declaration leads to a manual canonical-URL field. A valid result still does not navigate until I click again.

That extra click is deliberate friction. It is the product boundary.

Two rails with different meanings

The PayPal rail is deliberately boring: exactly 2.00 USD, fixed on the server, described as a voluntary gratitude tip. Provider fees apply and Thanks2Go does not promise a specific net amount. The client cannot change the currency, amount, payee, description, or return destinations. Creation and capture use separate stable idempotency identifiers, and a success receipt is issued only after PayPal confirms the exact capture. The API discards payer name and email and exposes only a one-way hash of the provider payer identifier.

The Solana rail is deliberately labelled devnet demonstration. I pinned @solana-commerce/kit 0.1.1 and use its headless createTipRequest primitive in SOL tip mode. A visitor selects one of three bounded values—0.001, 0.005, or 0.01 SOL—and receives a signed ten-minute mandate. The transaction builder adds a read-only reference derived from that mandate's hash and exactly one matching memo. The server verifies finality, recipient, amount, signature, time window, reference, and memo before producing a receipt. Devnet tokens have no monetary value, and the interface says so at the decision point.

The general QR, when present, contains only the canonical profile URL. It never contains a wallet destination or an executable payment.

What the agents are allowed to do

Thanks2Go has two first-party A2A agents using the official JavaScript SDK and the v1 SendMessage JSON-RPC method.

The Payer Intent Agent can stage an exact mandate after a rail and amount are selected.
The Recipient Trust Agent can report evidence that the canonical origin and configured rail destination are controlled.

Their Agent Cards are signed with the same ES256 service identity published through JWKS. They answer immediately with an A2A Message; there is no persistent task history.

I used AP2 as a conceptual decomposition—intent, bounded mandate, visible approval, provider action, receipt—but I do not claim AP2 conformance. I also do not turn agent context into identity. Thanks2Go can say “origin controlled” and “destination controlled.” It cannot say “real person,” “safe profile,” or “human identity verified.”

WebMCP as progressive enhancement

When document.modelContext exists, the page registers four experimental WebMCP tools:

inspect_gratitude_profile
stage_gratitude_intent
open_payment_handoff
verify_gratitude_receipt

No tool can set approval to true, create or capture a PayPal order, or sign a Solana transaction. The normal interface works when WebMCP is absent.

This was an important design test for me. Agentic software becomes more useful when its authority is explicit; silently upgrading every useful action into autonomy weakens that trust.

I then asked a browser agent to inspect the product as if it had never seen the implementation. It understood the main boundary, yet it still had to guess whether an origin-control field was independently verifiable, whether a valid credential meant a settled payment, and whether the page had exposed unrelated browser secrets. That uncertainty became a contract test.

The inspection tool now reports the current origin, its match with the canonical profile, the transport state, the JWKS and signed Agent Card locations, and explicit paymentInitiated: false and secretsReturned: false fields. The staging tool exposes a recipient-control credential while withholding the signed payment mandate. Receipt verification separates cryptographic validity from confirmed settlement and from usability as payment proof.

After that bounded refinement, webmcp.com's external scanner graded the deployed page B+, detected all four tools, and recognized rigorous schemas and clear safety invariants. The product remains one deliberate page; I chose a narrow journey over pages created only to improve a coverage score. The grade is dated September 4; index presence was checked separately on September 5. It is not a security certification.

The work behind webmcp.com deserves its own acknowledgement here. Its public scanner and evaluation method gave me an immediate agent-facing review instead of leaving me to guess whether the tools were understandable from outside my own code. The feedback made refinement faster and easier: I could see which schemas needed precision, improve the contract once, redeploy, and verify the result. That kind of practical evaluation surface helps WebMCP move from an experimental browser capability toward something developers can test, compare, and improve with evidence.

Receipts without a gratitude database

Each mandate is signed, self-contained, audience-bound, nonce-bearing, idempotent, and valid for at most ten minutes. Provider state remains the source of truth. A confirmed result becomes a W3C Verifiable Credentials Data Model 2.0-shaped receipt in an application/vc+jwt-compatible ES256 envelope.

This removes the need for a database of who thanked whom. It does not erase provider retention or the public nature of a blockchain. The privacy page says both plainly.

What I tested

The automated suite covers canonical URLs, amount constraints, deterministic hashes, expiry, JWT tampering, API origin checks, the approval gate, signed Agent Cards, a real inter-agent A2A v1 exchange, MV3 permissions, conflicting declarations, and the absence of payment authority from WebMCP.

The release gate separately requires provider evidence: PayPal sandbox success, cancellation, refusal and idempotent retry; a separately confirmed live 2 USD capture; Solana devnet acceptance, cancellation, mismatched recipient/amount/reference and finality; keyboard, screen-reader, mobile and Chrome passes; GitHub Actions; TLS; and the public deployment.

At the September 5 verification checkpoint, 103 automated tests passed and GitHub Actions was green. Production checks exercised signed A2A exchanges and all four native WebMCP tools. PayPal sandbox success, cancellation and idempotent retry were verified; documented provider negative testing covered failure responses. A merchant screenshot showed a completed live 2 USD payment from a separate consenting payer. A 0.001 SOL devnet transfer was independently verified as finalized to the configured recipient, and Thanks2Go verified its signed receipt. Remaining work includes correlating and verifying the live PayPal application receipt, the outstanding browser QA, and the final demo recording.

The part that surprised me

I entered the weekend thinking I was building a small generosity tool. I ended up seeing my own last five years differently.

The technical work matters: strict contracts, a minimal extension, two payment rails, agent cards, verifiable receipts, threat models, tests. But the more important realization is that knowledge can become invisible to the person who carries it every day. The way back to curiosity was to place that knowledge in service of someone else—and then be disciplined enough to protect them from what the software should never decide.

Gratitude can travel quickly. Approval should still belong to a person.

Prize Categories

I am entering Best Use of Solana.

Thanks2Go uses @solana-commerce/kit 0.1.1 in tip mode on devnet. Commerce Kit prepares the bounded headless tip request; Thanks2Go constructs the native SOL transfer and adds a mandate-derived reference and memo, then verifies finality, recipient, exact amount, reference, memo, signature, and time window on the server before issuing a receipt. The interface identifies this rail as a devnet demonstration at every decision point.

Project Links

Live profile: https://thanks2go.securedme.ca/p/securedme
Source: https://github.com/SeCuReDmE-main-dev/thanks2go
Challenge: https://dev.to/challenges/weekend-2026-09-03

Companion podcast

Why Thanks2Go rejects frictionless design — companion audio;

Why Thanks2Go rejects frictionless design - Google Drive

drive.google.com

Summer Gate: What WebMCP-QCG Taught Me About A2A and Human Authority

Jean-Sebastien Beaulieu — Wed, 02 Sep 2026 17:03:08 +0000

During the final days of WebMCP-QCG, I stopped asking what else I could add.

I started asking a harder question:

Could someone understand and verify this project without me standing beside them?

That question changed the work.

WebMCP-QCG is a browser-native preflight workbench for quantum-development decisions. It can inspect a bounded artefact, evaluate a proposed action, present a recommendation, stop for human authorization, run a supported local classical simulation, and export an evidence receipt.

It does not reach a QPU. It does not promise quantum advantage. Most importantly, it does not allow an agent to make the final decision for the human.

Three surfaces, one shared truth

The project now operates across three connected surfaces:

the Web application, where the artefact and human decision remain;
a QCG panel inside browser DevTools;
a persistent Companion side panel for inspection, collaboration, accessibility and evidence.

These surfaces share the same sanitized state, but they do not share every capability.

Raw quantum source remains inside the page. Consent tokens, credentials and private paths never cross into the extension. The Companion can inspect, explain and coordinate, but it cannot create consent or quietly transform a recommendation into authorization.

This separation became my most important lesson from the hackathon.

Listen to the short Companion podcast

What A2A should protect

Before this project, agent-to-agent communication felt like an architectural possibility. After building the Companion, it became tangible.

One agent can inspect. Another can challenge the first analysis. A human can compare their observations. The application can enforce its local boundary. A receipt can preserve what happened afterward.

That is the A2A-shaped collaboration I want to continue building: several systems contributing without merging their responsibilities.

Gemini participates through a deliberately manual and sanitized handoff. I am not claiming a native Gemini DevTools API or a complete authenticated A2A server. The useful mechanism is simpler and already real: recommendations can travel while human authority remains visible.

Clarity helps agents and humans

Direct use exposed another important problem. The first Light version of the Companion was too bright and visually tiring. Controls that looked acceptable on a large design canvas became harder to read inside a narrow persistent panel.

I refined the palette, contrast, focus indicators and accessibility controls through actual browser use. That reinforced a lesson I want to carry forward: clarity created for agents is also useful to humans.

Named states, explicit controls, readable history and predictable navigation reduce ambiguity for everyone. Accessibility is not decoration added after the engine. It is part of the interaction contract.

I invited cold judges into the process

By Day 7, I was too close to the project to trust familiarity alone.

I used external AI reviewers as cold judges. Their role was not to praise the architecture. Their role was to approach the repository like unfamiliar evaluators, identify fragile assumptions and force every concern back against the real code.

Some findings became corrections. Some became tests. Some required documentation. Others were rejected because the claimed defect did not match the implementation.

The human decision remained mine, but the counter-analysis made that decision stronger.

Why I continued

During these days, I helped an expert collaborator transform specialized knowledge into a professional publication. His passion was real, the purpose was visible, and I could strengthen the delivery without taking ownership of his work.

At the same time, an unclear professional request reminded me how quickly hope and intellectual attention can be consumed when identity, scope and commitment remain undefined.

Those situations were two views of the same avenue.

I want to help people build meaningful tools, even when they arrive without perfect technical language. But generosity needs trust, purpose and boundaries.

I did not finish this project only for a prize. I finished because I want to be ready when someone writes with a real dream and honestly asks for help.

Read the full Summer field report

The complete English and French editions belong to one canonical publication family:

Summer Gate: The Ending Belongs to the Evidence / La porte de l’été : la conclusion appartient aux preuves

The final video and submission remain outside this journal. If you want to see how the story ends, the evidence is public:

I built the gate so decisions would follow evidence.

I intend to close the hackathon the same way.

Protect Your Heritage. Secure Our Legacy.

Day 5 of WebMCP-QCG: I Stopped Adding and Started Proving

Jean-Sebastien Beaulieu — Mon, 31 Aug 2026 20:10:30 +0000

Day 5 began with one of the most dangerous moments in software development:

the product worked.

That is exactly when my brain becomes a hackathon vending machine. I press one successful feature and six new ideas fall out. More providers. More languages. More panels. Better graphics. Deeper memory. A smarter agent. Another integration that will only take twenty minutes.

This time, I stopped.

WebMCP-QCG already had a working foundation. My job had changed. I needed to turn it into a product I could demonstrate, measure, defend, and finish.

Day 5 became the day I stopped collecting possibilities and started collecting proof.

The gate had to earn every next action

WebMCP-QCG operates before a costly or consequential quantum operation.

A quantum artefact enters the browser. QCG computes its real SHA-256 digest, identifies its capabilities, evaluates the intended operation, explains one recommendation, asks for a human decision when authority is required, and produces an evidence receipt.

Its four quantum tools cover four responsibilities:

inspect the experiment;
evaluate the proposed call;
run a bounded local simulation;
export the evidence report.

The decision engine can recommend reuse, rejection, recompilation, local simulation, or readiness for a later external workflow. Readiness describes evidence. Authority belongs to the person operating the gate.

An agent can recommend. The application can validate. I decide.

The feature freeze became part of that architecture. It redirected the remaining effort toward accessibility, recovery, testing, interface coherence, documentation, deployment, and receipts.

For once, my backlog did not get to eat my release alive.

The interface had to become mine

The seasonal interface helped me discover the product, but the application needed a durable technical identity. The four seasons now belong to the editorial series: Autumn for emergence, Winter for discipline, Spring for proof, and Summer for closure.

QCG itself became a browser console.

A navigation rail controls a central workbench. Inspector, Console, WebMCP, Decisions, Sources, Receipts, and Activity each have a real job. A persistent evidence panel keeps integrity, recommendation, authority, participants, and review requests visible.

The same sanitized state can appear across three surfaces:

the website;
a dedicated QCG panel inside Chrome DevTools;
a browser companion side panel.

Accessibility became architecture during the redesign. Keyboard navigation, visible focus, semantic labels, responsive reflow, contrast, reduced motion, and an accessible splitter improve the experience for people while giving browser agents a clearer interface to understand.

Dark and Light became the product themes. Cyan identifies active technical state. Emerald marks safe primary actions. Gold identifies human authority. Red is reserved for refusal and error.

The console finally looked and behaved like QCG.

Conversation became useful because authority stayed separate

I wanted Codex, Gemini-oriented clients, the website, DevTools, and the side panel to contribute to one investigation.

The practical solution was shared, bounded application state.

Compatible MCP clients can target the same browser page, read sanitized context, post observations, challenge a hypothesis, and request human review. QCG records the declared actor, intent, confidence, references, sequence, and resolution state.

Gemini inside DevTools follows a visible human relay. QCG prepares a sanitized handoff package. I can copy it into Gemini, review the response, preview the structured result, and explicitly import it into the ledger.

That boundary gives the collaboration its strength. Agents can debug, search, find, brainstorm, and request a decision. The person applies the disposition. A collaboration message carries evidence; quantum consent comes from the active human workflow.

My goal is to give the human a much better loop.

Ten profiles, two executable paths

The quantum surface expanded through explicit capability contracts.

QCG now recognizes ten ecosystem profiles. Q# and OpenQASM earned executable status through the same bounded QDK/WebAssembly Worker. Eight additional profiles support static inspection: Qiskit, Cirq/TensorFlow Quantum, TorchQuantum, PennyLane, CUDA-Q Python, CUDA-Q C++, Amazon Braket, and textual QIR.

Recognition means QCG can identify relevant structure, calculate a real digest, expose capability facts, and produce a reviewable recommendation. Execution means the runtime has earned that status through limits, fixtures, tests, cancellation, receipts, and human consent.

I am building a preflight workbench. Every future adapter now has a clear graduation path: define the capability, implement the boundary, test the state, preserve the receipt, and identify the authority required for the next effect.

Then I made the numbers mean something

I finished Day 5 with a staged E2B campaign against the deterministic decision engine.

The campaign progressed from local validation to 10 sandboxes, then 50, then 100 concurrent sandboxes. Two complete million-operation passes produced matching digests across all 100 environments.

The consolidated record contains:

2.6 million validated decision-engine operations;
100/100 matching sandbox digests;
zero unauthorized effects;
zero missing receipts;
zero decision mismatches;
zero surviving sandboxes after cleanup.

These numbers measure reproducibility in QCG's decision and evidence engine. Quantum performance belongs to a different experiment.

I tested delivery separately. A deliberately small cPanel canary sent 80 requests to the public origin. All 80 returned HTTP 200, with zero errors and zero timeouts. That receipt measures delivery health.

Measurements become useful when I let them describe the system they actually measured.

The canonical application is now live. The regression suite remained green, the reviewed build matched the deployed origin, and the functional product entered feature freeze.

I still have ideas. Of course I do. My brain opened several imaginary repositories while I wrote this sentence.

They can wait.

This work matters to me because I think about my children and the learners whose hardware, geography, or budget narrows their access to advanced systems. A browser-native gate can reduce the knowledge and coordination cost of approaching quantum work responsibly. It can help a person understand what can run locally, what should be reused, what needs another target, what evidence exists, and who controls the next action.

Spring is often described as uncontrolled growth. I learned another version of it.

Growth becomes durable when the roots, branches, and limits develop together.

On Day 5, I stopped adding. I started proving.

Explore the project

Research-partner disclosure

I used Codex and Gemini in Browser to its fullest potential as a research partner—for code mapping, source comparison, evidence organization, consistency checks, editorial control, and deliverable preparation. I formulated the intent, defined the scope, interpreted the results, arbitrated the conclusions, and preserved every public decision. This collaboration expands my investigative capacity; judgment, responsibility, authorship, and final signature remain under my authority.

let go 12 years old hen i wish i was that awake at 12 let gooooo i will follow and encourage you for sure let gooooo keep on building

Jean-Sebastien Beaulieu — Sun, 30 Aug 2026 16:23:31 +0000

Harun - solo dev

Aug 26

🚨 ANNOUNCING: The First Ever "KODA Code Jam"!

2 min read

Winter Gate: My Browser Waited for My Decision

Jean-Sebastien Beaulieu — Sun, 30 Aug 2026 15:20:54 +0000

Days 3–4 of building WebMCP-QCG

I slept before Day 3.

That sounds like a small achievement in a development journal, but it changed the architecture. My most useful optimization was giving the human operator a full night of RAM.

I returned to WebMCP-QCG rested enough to see the project clearly. I had begun with an ambitious quantum router spanning frameworks, simulators, providers, notebooks, processors, and several futures at once. The map was exciting. The product was hiding inside it.

Then one question gave the project its purpose:

Before an agent asks a quantum system to do something, has that call earned the right to run?

That question turned the router into a gate.

One artifact enters the browser

The transaction begins with a real Q# file selected by the human.

QCG reads it locally, computes its SHA-256 digest, records its provenance, and compiles it through a bounded browser Worker. The agent receives a structured artifact identity rather than a loose description of the experiment. It can inspect the manifest and evaluate the intended action against explicit limits.

The result is one recommendation:

reuse fresh evidence;
reject an unsupported call;
recompile for the selected target;
simulate locally first; or
mark the experiment technically ready for a later external workflow.

Technical readiness is a statement about evidence. Authority is a decision made by a person.

The moment the machine waited

My favorite state is simulate_first.

The recommendation appears. The reason codes are visible. The proposed limits are visible. Then the system waits.

That pause is the product.

If I accept, QCG creates a short-lived, single-use consent for one bounded local simulation. The Q# Worker runs the experiment, returns its histogram, and consumes the consent. If I defer, the experiment remains where it is. If I override the recommendation, the receipt preserves my choice and justification instead of rewriting the history into a cleaner story.

In the validated Bell path, the browser completed 64 correlated shots. The effect counters recorded one local simulation and zero provider or QPU submissions. The receipt linked the artifact digest, compiler version, policy, recommendation, human decision, and measured effect.

For the first time, I could follow the whole chain and explain every transition.

Four tools with four responsibilities

WebMCP-QCG now exposes a deliberately small surface:

inspect_quantum_experiment
evaluate_quantum_call
run_bounded_qsharp_simulation
export_quantum_evidence_report

The third tool only appears when the recommendation, application state, and visible human consent all agree. The fourth exports what already happened; it does not silently re-evaluate the experiment.

This separation gives each tool one responsibility and gives the browser a history that both a human and an agent can inspect.

The current codebase passes 34 automated tests across six files and builds 127 TypeScript/Vite modules. Those numbers matter because they describe the proof I actually have. They also reveal the next work: live browser lifecycle testing, the optional QCG panel in Chrome DevTools, deployment parity, and a clean multi-agent handoff.

A room for agents, with one human gate

I am now extending this discipline into DevTools.

The goal is a shared debugging room where Codex can map contracts and regression risks, a Gemini-oriented client can challenge the browser diagnosis, and I can compare both contributions. Each observation will keep its declared actor, evidence references, confidence, and review state.

The collaboration tools may read context, post an observation, request human review, and export a handoff. Quantum consent and execution remain in the primary QCG workflow.

This is the future of browser agents that interests me: several capable systems contributing evidence while their responsibilities stay legible. Intelligence can be distributed. Authority still needs an address.

Why Winter matters

The first article belonged to Autumn. It captured discovery: gold light, a closed gate, and ideas arriving faster than I could classify them.

Winter represents structure. Bare branches reveal the load-bearing parts. Footprints remain visible. Every feature must show the evidence that earned its place.

I am building this for more than a hackathon. I see a future where students, independent researchers, and developers with ordinary computers can prepare meaningful quantum work through a browser. Local simulation, cloud infrastructure, and physical processors will keep different roles. A clear gate can help people understand which path fits their experiment before cost, complexity, or automation carries them forward.

That matters to SecuredMe. It matters to the educational tools I want my children and future students to inherit. Powerful systems should teach judgment alongside capability.

At the end of Days 3 and 4, the project felt alive for a new reason. It had learned how to wait.

The browser can inspect. The policy can recommend. I decide when the gate opens.

Explore the work

Day 2 of Building a WebMCP Quantum Tool: My Brain Filed a Complaint

Jean-Sebastien Beaulieu — Fri, 28 Aug 2026 05:17:49 +0000

Day 2 of this hackathon research phase was not a calm engineering day.

It was a full-contact learning marathon.

I went through webinars, repositories, specifications, quantum tooling, WebMCP material, Qiskit refreshers, Azure Quantum memories, CUDA-Q direction, Colab possibilities, browser execution models, and enough “let me just read one more thing” moments to make my eyes negotiate directly with gravity.

At one point, I was so tired that I almost fell asleep on the keyboard, woke up half-panicked, and became convinced I had erased something important.

I had not.

My keyboard survived. My project survived. My mind is still under review.

And somewhere in the middle of all this beautiful technical indigestion, the project became clearer.

The Project Is Now Quantum

At the beginning, I still had multiple possible directions.

One idea was WebCCP: a continuity contract between surfaces, tools, and agents. I still believe there is something important there. But after the WebMCP/CCP article, I understand the weight problem better. Context has a cost. Carrying continuity blindly can become expensive very quickly.

So WebCCP stays on the bench.

Another idea was a WebMCP website design assistant. Honestly, that one would probably be easier to present. It would be practical, visual, and much simpler to explain in a demo.

But simple is not always the project that teaches the most.

The direction I am choosing is quantum.

More precisely: a WebMCP Quantum Call Gate.

Not a full quantum IDE. Not a replacement for Qiskit, CUDA-Q, TensorFlow Quantum, TorchQuantum, Azure Quantum, or Colab.

A call gate.

A decision layer.

A tool that helps an AI agent decide what should happen before a quantum execution is launched.

The Real Problem

Quantum work is expensive in multiple ways.

It costs attention. It costs compute. It costs cloud access. It costs shots. It costs time. It also costs mistakes, because a weak prompt or a badly framed execution can send work to the wrong backend for the wrong reason.

A quantum specialist does daily work like:

build circuits from gates
compile circuits for execution
use primitives to build and execute experiments
visualize circuits and analyze results

Those actions are normal in quantum workflows.

But when an AI agent enters the browser and starts helping, another question appears:

Should this action run at all?

Should it run in the browser?

Should it run in Colab?

Should it target Qiskit?

Should it use CUDA-Q?

Should it stay as a local simulation?

Should it ask for confirmation before burning real resources?

That is the space I want to explore.

What The Webinars Taught Me

The webinars were useful, even when my soul briefly left the room.

Some of them were exciting. Some were technically valuable but delivered with the emotional temperature of a filing cabinet. That is not an insult. It is just the reality of learning while tired. When you already understand part of a topic, the speaker’s energy matters. A lot.

The Azure Quantum material reminded me of something important: quantum in the browser is already possible. WebAssembly, browser-hosted tooling, VS Code web experiences, and fast feedback loops are real. That matters because it proves that the browser is not only a documentation surface. It can be a technical surface.

CUDA-Q pushed the idea further: the useful abstraction is not only the circuit. It is the target. The backend. The processor. The place where the work will actually run.

That changed my MVP thinking.

I do not want to build a toy that says “here is a circuit.”

I want to build a tool that says:

“This request should run here, for this reason, with these limits, and these risks.”

That is much more useful.

The Funny Part: I Am Doing This To Stay Grounded

There is a moment in every serious learning marathon where the brain starts asking spiritual questions.

Why am I watching another webinar?

Why am I reading another specification?

Why am I comparing four quantum ecosystems when I could be sleeping?

Why did I think this was a normal Tuesday?

Then I remember.

I am doing this for SecuredMe.

I am doing this for the education suite.

I am doing this for my kids.

I am doing this because I want advanced technical systems to become more accessible to people who do not have perfect hardware, perfect funding, perfect institutional access, or perfect timing.

That part matters to me.

My laptop is not a supercomputer. It can run code. It can compile. It can build. But it is not the right place to run a heavy local AI agent or a large quantum stack.

So the architecture has to respect that reality.

Local orchestration. Browser interaction. Cloud or Colab when needed. Clear routing. Clear proof. Clear decision.

That constraint is not weakness. It is product truth.

The Tool I Want To Build

The working name is:

WebMCP-QCG: WebMCP Quantum Call Gate

The MVP should demonstrate one clean vertical path:

A user asks for a quantum action from the browser.
WebMCP exposes a small set of non-overlapping tools.
The call gate evaluates the request.
It identifies the likely framework and execution surface.
It explains the decision.
It either approves a safe local/browser/Colab action or refuses/defers a risky one.
It produces a short trace that a human can inspect.

That trace is important.

I do not want an agent that silently “does quantum.”

I want an agent that can justify why it chose a backend, why it avoided another one, and what evidence it used.

That is the real product.

What I Am Not Building This Week

This part is where I have to be disciplined.

Because my brain immediately wants the full system.

Circuit builder. Gate designer. Custom gates. Multi-framework export. Colab execution. CUDA-Q backend selection. Qiskit integration. Azure adapter. TensorFlow Quantum compatibility. TorchQuantum bridge. Visual debugger. Educational mode. Research report generator. Cost estimator. Classroom mode. Children’s learning layer.

All of that is interesting.

All of that can exist later.

This week, the MVP must prove the call gate.

The win is not to build the entire quantum universe inside a browser tab.

The win is to show that an AI agent can pause before execution, inspect the request, select the right surface, and explain the decision in a way that protects the user from wasted compute and bad assumptions.

The Hackathon Angle

I am entering this hackathon knowing that my location may prevent me from winning.

That changes nothing about the value of the work.

I will still respect the rules. I will still build in public. I will still submit the project properly. I will still keep the repository open as the work evolves.

For me, this hackathon is not only a contest.

It is a nine-day training camp.

It is a way to force myself to understand AI in the browser before 2027 makes this normal.

It is a way to sharpen SecuredMe’s future architecture.

It is also a way to open my process and make the competition stronger. If someone reads my notes and builds something better, good. That means the field moved.

I would rather contribute loudly than wait quietly.

Codex In The Process

I used Codex to its fullest potential as a research partner: for code mapping, source comparison, evidence organization, consistency checks, editorial control, and deliverable preparation.

I formulated the intent, defined the scope, interpreted the results, arbitrated the conclusions, and preserved every public decision.

This collaboration enhances my investigative capacity; it places judgment, responsibility, and signature under my authority.

That distinction matters.

The AI partner helps me move faster.

The decision remains mine.

Day 2 Conclusion

Day 2 hurt a little.

In a good way.

It was the kind of day where learning becomes physical. Eyes tired. Brain saturated. Notes everywhere. Webinars half-finished. Ideas arriving faster than I can organize them. A few moments of genuine confusion. A few moments of clarity strong enough to keep going.

The project is now clearer:

I am not building a general quantum platform.

I am building a WebMCP call gate for quantum work.

A small, inspectable, useful decision layer that helps an AI agent decide before it executes.

That is the right size for the hackathon.

That is the right bridge between WebMCP and quantum tooling. Habitually i do vid and podcast and trilangue fuck that tonight im fabergast i still have produce a full editorial long english companion article

but only in english sorry for those fictive reader that read my spanish version who know maybee one day i will have a spanish reader!!!!

And tonight, now at the right moment I am going to sleep on it.

Because after 37 hours in 48 hours, the next architectural review belongs to my dreams.

I Judged an AI Ops Alpha Too Quickly—Then I Read Its Security Boundary

Jean-Sebastien Beaulieu — Wed, 26 Aug 2026 04:55:52 +0000

At 2:01 a.m., Zheng Qi sent me a question that shaped the next twenty-two hours of my life:

What would you trust an incident-triggered AI operations engineer to do?

I opened NoPager expecting to evaluate an ambitious Alpha. The visible product felt younger than the promise. My first instinct focused on the interface, the setup experience and the distance between an early screen and a production-grade claim.

Then I read the code.

That changed the entire investigation.

Behind the early interface, Zheng had built something far more serious: a security boundary designed to keep AI reasoning separate from production mutation.

This article is the short version of what I learned—and why I changed my mind.

The real question is authority

People often ask whether an AI agent is intelligent enough to operate infrastructure.

I now think that question arrives too early.

The first question should be:

Which authority can this system exercise when its reasoning becomes wrong, incomplete or surprising?

A language model can produce a brilliant diagnosis and still generate an unsafe next step. Reliability therefore comes from architecture rather than confidence in the model’s judgment.

NoPager approaches this by dividing the system into distinct powers:

an external monitor detects repeated health failures;
an AI worker receives bounded evidence and proposes an action;
deterministic policy decides whether the proposal fits the operator’s rules;
a narrow privileged helper validates and executes the permitted mutation;
an independent signal verifies recovery;
the operator retains the Kill Switch and escalation path.

The model receives the power to propose. The helper receives the power to perform a tiny catalogue of operations. The operator retains the power to define the catalogue.

That is a much stronger foundation than asking an AI to “be careful.”

Six dimensions changed how I evaluate agents

During the review, I began mapping production authority across six dimensions:

Actor — Which authenticated component is asking?
Verb — Which exact operation may it request?
Target — Which enrolled resource may receive it?
Quantity — How many mutations fit inside the policy?
Time — Which cooldown, deadline or TTL limits the action?
Proof — Which durable record and independent signal establish the outcome?

This map gives us a practical way to evaluate automation.

A read-only evidence collector can receive broad observational access inside a bounded incident window. A container restart can receive narrow automatic authority for one immutable target. A database failover, durable WAF change or destructive operation belongs behind explicit human approval until field evidence supports a safer contract.

The AI can reason widely. Its mutation authority remains small.

The worker/helper split is the heart of the design

The most important change I studied came through NoPager’s worker/helper architecture.

The worker runs with restricted privileges. It lacks direct Docker authority. It produces a typed request selected from a pre-approved action catalogue.

The host-side helper holds the narrow privilege. It validates the Unix peer identity, a local credential, the enrolled Docker target and control-plane exclusions. The helper receives a structured request rather than a free-form shell command.

This creates a physical gap between reasoning and execution.

Even a deeply confused model reaches the same narrow gate.

A green test suite is the beginning of trust

Source review showed strong implementation discipline. Yet production trust requires several kinds of evidence.

I use three levels:

Code confidence — the intended controls and invariants exist;
Laboratory confidence — those controls survive concurrency, corrupted state, timeouts and interrupted dependencies;
Field confidence — a real operator can install, understand, approve, interrupt and recover the system under realistic pressure.

This distinction matters for every AI product. Unit tests can prove a policy branch. A disposable Linux environment can prove socket behavior during failure. A design partner can prove whether the operator actually understands the boundary at 3 a.m.

Each proof answers a different question.

Ambiguity is a first-class state

One of the most valuable lessons came from the durable request journal.

An operation may be ready, active, completed or historically ambiguous.

That last state deserves special attention. Imagine a helper restarting a container while the process, Docker daemon or host loses connectivity. The system may lose the ability to prove exactly what happened.

A careless orchestrator retries. A safer system records the uncertainty, freezes the mutation path and escalates to a human.

This is where idempotency becomes more than duplicate protection. It becomes a statement about operational truth.

The lesson travels far beyond container restarts:

An unknown outcome deserves an explicit recovery path.

Security must become visible in the interface

The code changed my judgment of NoPager. The next opportunity is helping the interface communicate what the engine already protects.

A solo operator should be able to answer five questions quickly:

What happened?
Which evidence supports the diagnosis?
Which action is proposed?
Which policy grants that action authority?
Which recovery path activates when history becomes ambiguous?

The product journey can make the authority flow visible:

Detection → Evidence → Proposal → Policy → Approval or Allow → Execution → Verification → Recovery or Escalation

Safe Mode then becomes a learning path. Autopilot becomes an earned transition for specific actions whose boundaries have already been observed, tested and accepted.

What I am carrying into my own work

This investigation gave me three lessons I want to retain:

First: reasoning capability and execution authority are separate design problems.

Second: a security control gains product value when the operator can see it at the moment of consequence.

Third: reviewing a project deeply enough to revise an initial judgment is part of responsible technical work.

Zheng builds NoPager as a solo maintainer. The repository shows an impressive pace and a serious effort to reduce authority before asking operators to trust the product.

I chose to contribute through research, an article, field-test protocols and public attention. The code remains under Zheng’s technical authority.

Explore the complete work

If this question matters to you, visit the project and offer one focused thing: an operator perspective, a design-partner experiment, a careful review or a word of encouragement.

For a solo developer, precise attention can become a meaningful contribution.

I Tried to Add Memory to WebMCP. The Experiment Told Me Not To.

Jean-Sebastien Beaulieu — Sat, 22 Aug 2026 14:18:06 +0000

I had a problem that looked like memory.

I could work for hours with an agent on my laptop, move into the browser, and discover that the objective had survived—but the decisions, constraints, evidence, and next action had not. The new surface knew what I wanted in general. It did not always know what had already been ruled out, what was still unproven, or what should happen next.

My first idea was straightforward: perhaps WebMCP needed a compact continuity package.

I called it CCP—the Context Continuity Package. It would be small, origin-scoped, read-only, rejectable, and designed to carry only the state needed to resume a task. I imagined it as a bridge between Codex, ChatGPT in Chrome, Antigravity, and Edge.

Then I did the thing that changed the entire project: before proposing a new primitive, I read WebMCP as if I were preparing for surgery.

The result was not the victory I expected. It was more useful.

I learned that the continuity problem is real, that a CCP can reduce part of its visible cost, and that WebMCP is probably not the layer that should own agent memory.

This is the story of the experiment, the code, the failures, and the architectural boundary I found.

Why I chose WebMCP

I have followed WebMCP since its early development. For a long time, I watched the repository and its discussions more than I participated. I did not yet trust my understanding enough to enter a specification conversation with Chrome engineers.

Meanwhile, my own work kept returning to the same question: what makes an agentic system genuinely useful?

Swarm size is not enough. A hundred agents with poor tools can still fail in the same place. RAG, human-in-the-loop workflows, memory systems, and orchestration matter, but eventually an agent must act through the interfaces it is given. The quality of those interfaces determines what it can discover, what it must absorb, and what it can safely do.

That made WebMCP the right place to learn. It exposes structured page capabilities to agents. It sits close to the moment where intention becomes action.

But being close to a problem does not mean owning it.

The audit changed the question

I started with the question:

Where should CCP be placed inside WebMCP?

After auditing the repository, WebIDL, Bikeshed algorithms, lifecycle rules, origin boundaries, security notes, contribution history, and 247 GitHub objects, the question became:

Can the existing imperative WebMCP tool carry a rejectable continuity packet, and what defect—if any—would still belong to the platform?

That reformulation was decisive.

WebMCP exposes capabilities from a page. The browser mediates those capabilities. The agentic harness decides what the model sees, retains, compacts, or forgets. The product decides how conversations, sessions, telemetry, and model selection are presented.

CCP could travel through WebMCP without becoming WebMCP memory.

This boundary also corrected several security assumptions.

readOnlyHint and untrustedContentHint are annotations, not enforcement.
Same-origin limits scope, but it does not make content truthful or harmless.
A digest proves that canonical bytes did not change; it does not prove that provenance is authentic.
A tool visible in a browser is not necessarily discovered or invoked by the agentic product.
CDP automation, DOM reading, and native WebMCP invocation are different evidence chains.

That last distinction became central to every test.

Building a packet the agent could refuse

The laboratory remained outside the upstream WebMCP checkout. I did not modify the specification repository.

The experimental contract, ccp.webmcp.experiment.v1, contained:

an origin and task scope;
declared producer, revision, creation time, and digest;
objective, constraints, decisions, evidence references, completed work, blockers, and next actions;
freshness and expiration state.

The initial limits were intentionally experimental: 8 KiB maximum, bounded arrays, and a 24-hour expiration window. The packet excluded transcripts, secrets, cookies, account identifiers, personal data, and cross-origin authority.

The validator parsed before building the business object, rejected duplicate keys, canonicalized JSON independently, checked RFC 8785 vectors, measured exact UTF-8 bytes, and returned stable error codes. The tests included hostile but correctly hashed content, false provenance, foreign origins, altered digests, expired packets, oversized payloads, Unicode edge cases, and forbidden data.

The most important finding was not that validation worked. It was understanding what validation could not establish.

A valid packet can still lie.

Five conditions designed to contradict me

I did not want a demonstration that made CCP look good. I wanted an experiment capable of showing that it was unnecessary.

Every condition came from the same controlled snapshot:

no context;
full history;
a free summary matched to the CCP byte budget;
CCP copied manually;
CCP retrieved through WebMCP.

The scorer checked required facts, the correct next action, stale-state contamination, hallucinated claims, unsupported certainty, clarification requests, and task completion. The order was counterbalanced across repetitions.

The protocol created 100 trial slots across four surfaces, five conditions, and five repetitions. Eighty manual trials were recorded, while the twenty WebMCP or relayed positions were classified separately so that a browser response could not masquerade as a native invocation.

The manual CCP performed well on the controlled resumption task: it recovered the correct action in 19 of 20 completed manual trials, the same count as full history. The matched free summary recovered it in 14 of 20.

That was evidence that structured continuity could be useful.

It was not evidence that WebMCP needed a memory primitive.

Origin Trial activation was only the beginning

The Origin Trial was activated on the registered laboratory origin. The server delivered the token through the Origin-Trial header, Chrome accepted it with the experimental flag returned to its default state, document.modelContext became available, the tool registered, and the page-side hook executed.

Those observations proved activation.

They did not prove product discovery.

The test chain had to remain explicit:

token delivered → token accepted → API present → tool registered → tool discovered → tool invoked → result used

Antigravity produced two server-confirmed native invocations out of five attempts in the relevant series, and one produced a usable resumption report. In the observed ChatGPT/Chrome and Edge configurations, the server confirmed no native invocation. Codex produced useful external relays, but those relays were labeled as relays rather than native WebMCP discovery.

This was not one generic failure called “unsupported.” It was a map of where each chain stopped.

The token-efficiency experiment complicated the result

My daily concern was not only continuity. It was cost.

When an agent enters the browser, visible context can include the operator prompt, previous history or CCP, tool names, descriptions, schemas, call arguments, results, and the final answer. Shrinking only the memory component does not necessarily shrink the whole interaction.

I therefore added an appendix experiment in Antigravity with five configurations:

eager_full: complete history, twelve full tool contracts, verbose results;
eager_ccp: optimized CCP, twelve full contracts, verbose results;
progressive_full: complete history with progressive capability discovery;
bounded_full: complete history with bounded results;
optimized_combined: CCP, progressive discovery, and bounded results.

I measured exact UTF-8 bytes and used a pinned local Hugging Face tokenizer as a reproducible proxy. I also recorded the visible Antigravity quota gauge, but never converted it into internal Gemini tokens.

In completed trials, eager_ccp reduced average visible context by approximately 27% in bytes and 25.1% in proxy tokens compared with eager_full. Bounded results reduced another independent component by about 21.2% in bytes and 19.6% in proxy tokens.

The theoretical optimized combination exceeded 50% before execution.

It did not pass the native pilot.

The progressive router was not reliably discovered, and the experiment ended PARTIAL. Only one of nine completed trials preserved all seven expected decision elements. The next action survived in eight of nine, but the complete micro-task succeeded only once.

So I cannot claim a 50% operational reduction. I can claim something more precise:

CCP reduced one real component;
bounded responses reduced another;
tool selection behavior could still double visible cost;
progressive discovery had the greatest theoretical potential and the weakest native evidence;
compression without decision fidelity is not optimization.

What I will not propose

I will not propose an RFC that adds CCP memory to WebMCP.

The experiment gave CCP a better address: the harness or agentic product. There it can remain a versioned, rejectable handoff contract. A complete envelope can serve the system, while a smaller projection can serve the model. The model does not “learn” by changing its weights during these handoffs; the surrounding system improves what it preserves, selects, and presents.

The questions most directly related to WebMCP are different:

How should a page expose many capabilities without front-loading every schema?
How can agents discover tools progressively?
How should results be bounded without hiding necessary evidence?
How can invocation be observed clearly enough to distinguish native integration from browser automation?

These questions already connect with ongoing WebMCP discussions about length and context inflation, tool filtering, dynamic definitions, and batch or code-mode execution.

My experiment does not resolve those issues. It provides a concrete case where initial context reduction is measurable, native discovery is uneven, and decision quality remains the guardrail.

A negative architectural result can still be a successful contribution

I began this work hoping to find a place for CCP inside WebMCP.

Instead, I found a reason not to put it there.

That is not arriving empty-handed. The work produced a repository audit, an external laboratory, an Origin Trial activation chain, 108 passing local tests, a 100-slot cross-surface matrix, 50 ablation results, a context-cost experiment, and a hypothesis that was corrected by evidence.

For me, the deeper lesson is about open-source participation. A professional contribution is not measured by how much architecture I can add. Sometimes it is measured by recognizing that the architecture already has the right boundary—and by returning with a smaller, more useful question.

Before building more agents, examine their tools.

Before adding memory to a protocol, identify who already owns retention.

Before celebrating fewer tokens, verify that the right decision survived.

And before writing an RFC, let the experiment earn the question.

Read or listen

Your Equation Is Not a Bridge: What Developers Can Teach Interdisciplinary Science

Jean-Sebastien Beaulieu — Wed, 19 Aug 2026 00:58:40 +0000

Full trilingual paper:

https://doi.org/10.5281/zenodo.22003225

Video essay:

https://youtu.be/frC1GCKFwME

I was reviewing a video generated from my latest article when an equation appeared on the screen:

E = mc² + Σ(φ) − ∞

It looked scientific.

It was also meaningless.

There was no defined summation domain, no dimensional consistency, and no valid reason to subtract infinity. The equation contributed nothing except mathematical decoration.

That tiny moment exposed the exact problem my article investigates.

A formula can compile visually while failing every meaningful type check.

Science also needs interfaces

Developers distrust a function when nobody can explain its inputs, output, contract, or failure conditions.

Yet interdisciplinary arguments regularly move between mathematics, physics, biology, neuroscience, and consciousness without declaring those interfaces.

A fractal pattern becomes a physical mechanism.

A frequency becomes biological information.

A neural signal becomes consciousness.

A mathematical limitation becomes evidence about matter.

Each transition sounds plausible because the vocabulary remains technical. But technical vocabulary cannot replace a valid transformation.

If this were software, we would reject the pull request.

bridge(
    object,
    scale,
    observable,
    operator,
    evidence
) -> defensible_inference

Remove one argument and the bridge becomes ambiguous.

Change the object halfway through and the program should throw an error:

InferenceError:
The conclusion refers to a different object
than the one that was measured.

That is the central idea behind Fractals, Waves, and Consciousness.

A snowflake is not automatically a fractal

The word fractal has become dangerously convenient.

A branching tree, a coastline, a neural network, a snowflake, or an irregular signal may resemble familiar fractal forms. Visual resemblance can generate a hypothesis, but genuine fractality requires a defined object, a range of scales, a measurement procedure, and an estimation method.

The box-counting relation

N(ε) ~ ε⁻ᴰ

has meaning only after defining what is counted, how resolution changes, and over which scaling window the relation remains stable.

A beautiful pattern is an observation.

A reproducible scaling law is evidence.

They are related, but they are not interchangeable.

Fourier uncertainty is not an ontology generator

Fourier analysis gives us one of mathematics' most powerful structural lessons: localization in one representation constrains localization in its transform domain.

The fractal uncertainty principle sharpens this idea for particular geometric supports. Results involving regular fractal sets and line porosity reveal how geometry can restrict simultaneous concentration.

That is extraordinary mathematics.

It still does not prove that every object displaying a fractal pattern vibrates, that every biological system inherits the theorem, or that consciousness follows from a Fourier inequality.

A theorem specifies its own domain.

Exporting it into another domain requires an adapter, not enthusiasm alone.

What do the measurements actually support?

The article travels through four difficult territories:

neutrino oscillations;
electrical behavior associated with microtubules;
anesthesia and consciousness;
the decomposition of proton spin.

These subjects do not occupy the same evidential level.

Neutrino flavor oscillations are supported by replicated experimental results.

Electrical oscillations involving microtubule preparations can be investigated experimentally, but a local signal does not establish a theory of consciousness.

The 613 ± 8 THz value discussed in the article comes from computational molecular modeling of tubulin and anesthetic interactions. It is an interesting modeled result, not a direct measurement inside a living brain.

The perturbational complexity index provides an operational way to analyze the complexity of brain responses following stimulation. It does not solve consciousness; it measures a defined response using a defined procedure.

Proton spin is experimentally established as a global property, while its decomposition among quark spin, gluons, and orbital angular momentum remains an active research problem.

The responsible conclusion is not that everything is uncertain.

It is that different statements possess different kinds of support.

The developer's advantage

Developers already possess useful instincts for this problem.

We ask:

What is the data type?
Where is the schema?
Which transformation was applied?
Is the output deterministic?
What assumptions entered the function?
What test would make it fail?
Did the implementation silently change the meaning of a variable?

Those questions belong in scientific reasoning too.

A productive interdisciplinary hypothesis should survive something resembling an interface-contract review:

def evaluate_claim(
    mathematical_object,
    physical_carrier,
    measurement_scale,
    observable,
    transformation,
    falsification_test,
):
    ...

If physical_carrier is None, we have an analogy.

If observable is undefined, we have a narrative.

If falsification_test is missing, we have a protected belief.

None of these are automatically useless. Analogies can inspire research. Narratives can organize questions. Beliefs can motivate years of work.

They simply need honest labels.

The equation that failed successfully

That fake equation in my video bothered me because it violated the argument being presented.

But it also gave me a perfect example.

The equation looked sophisticated, passed the visual test, and failed the mathematical contract. That is precisely how weak interdisciplinary arguments survive: they resemble valid work closely enough to avoid immediate rejection.

The solution is not to stop imagining.

The solution is to make imagination testable.

My collaboration with Hector Fernando Aguilar, M.D., reinforced that division of responsibility. Biological interpretation and mathematical formalization can inform each other without pretending to be the same expertise.

That is where productive collaboration begins: not when every participant knows everything, but when every transformation can be inspected.

What I now require from a bridge

Before accepting a claim connecting two fields, I want five things:

The object being studied.
The scale at which it is studied.
The observable actually measured.
The operator connecting input to output.
A test capable of proving the proposed connection wrong.

That standard does not eliminate speculative research.

It gives speculation somewhere solid to stand.

Mathematics offers more than impressive symbols. It gives us invariants, limits, transformations, and contradiction tests. Development offers more than implementation. It gives us contracts, reproducibility, failure handling, and adversarial debugging.

Together, they provide a practical discipline:

Never let an elegant output hide an undefined interface.

Read the complete English, French, and Spanish editions:

https://zenodo.org/records/22003225

Watch the companion video:

https://youtu.be/frC1GCKFwME

Scientific note: some equations appearing briefly in the generated video visuals are illustrative and are not claims made by the article. The reported 613 ± 8 THz shift refers to a computational molecular-modeling result, not a direct measurement in living neural tissue.