# EZ23 MCP Universal architecture lock

## 1. The connector is a function, not a daemon

The canonical deployment object is:

```text
Web Request → EZ23 → Web Response
```

`src/handler.js` exports that object directly. A Node listener, CGI launcher, Worker binding, serverless route, or stdio process is an adapter around it, not part of EZ23's causal/source-contact core.

This is the central change from v1.0.

## 2. Request-born and stateless

MCP 2026-07-28 is served per request. `createMcpHandler()` creates a fresh `McpServer` from `buildServer()` for each HTTP exchange. No MCP session identity, repository state, or source text needs to survive the request.

A warm serverless isolate may physically reuse loaded JavaScript code, but EZ23 correctness does not depend on that reuse. A cold invocation and a warm invocation follow the same custody path.

## 3. Private execution, public protocol surface

The MCP client's observable surface is:

```text
MCP tool schemas
MCP requests
MCP responses
```

The following are implementation details and are not returned automatically:

```text
JavaScript source
routing functions
GitHub fetch implementation
SHA-1 implementation
intermediate function calls
host adapter
filesystem location
```

To preserve that boundary on ordinary web hosting, keep the EZ23 package outside the document root and expose only a request launcher / function route.

## 4. Web-standard source-custody core

The EZ23 core contains no `node:*` imports and no `Buffer` dependency. It can operate anywhere the host supplies modern JavaScript plus outbound `fetch`.

Node-specific APIs exist only inside optional adapters.

## 5. Live router, pinned terrain

The connector does not hardcode a historical Mass Harmonics source baseline.

At runtime it:

1. reads the live EZ23 entrypoint;
2. discovers the current routing files;
3. reads the live machine Index Web and Source Lock;
4. verifies their commit/tree agreement;
5. obtains the currently sanctioned source baseline and per-source Git blob identities;
6. fetches actual source bytes from that exact baseline;
7. computes the Git blob SHA locally;
8. rejects mismatches;
9. retrieves the requested locator/anchor terrain.

Thus the connector follows future deliberately repinned versions without letting a moving branch silently replace its own pinned source objects.

## 6. Routing is not source contact

`ez23_route` only returns candidate retrieval handles from the current Index Web. It does not authorize a Mass Harmonics conclusion.

`ez23_contact` is the operation that reads and verifies the actual source object.

## 7. No persistent source cache

EZ23 stores no authoritative repository snapshot locally. Every substantive tool call reconstructs custody from the current live entrypoint/router/lock.

A hosting platform may cache executable code or TCP/TLS infrastructure internally; that is not Mass Harmonics source state and is not treated as authority.

## 8. `verify_index.py`

The current verification script is fetched because the EZ23 routing declaration requires contact with it. The connector does not execute changing remote code. Equivalent structural custody checks are implemented directly in the connector.

## 9. Fail closed

Any unresolved authority, identity, source, blob, locator, or requested retrieval handle produces:

```text
UNRESOLVED / SOURCE CONTACT INCOMPLETE
```

No plausible substitution is permitted.

## 10. Adapter rule

Adapters may translate transport/runtime mechanics only. They may not change:

- source authority;
- live router discovery;
- pinned-baseline enforcement;
- blob verification;
- routing/contact separation;
- fail-closed behavior.

That keeps the same EZ23 connector portable across request-driven hosts without creating platform-specific versions of the source-contact logic.