@reunionstudio/airlock-mcp 0.1.0

package/.agents/skills/airlock-mcp/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: airlock-mcp
+description: Design, draft, review, and iterate Airlock specs in the Airlock MCP spec-building workbench. Use when Codex is helping a person choose a small starting spec, work through row grain and OODA-loop decisions, import reusable patterns such as posts or guest access setups, validate local draft files, or prepare an Airlock spec config before installed Airlock validation.
+---
+
+# Airlock MCP Spec Builder
+
+Use this skill to help a human develop Airlock specs over multiple sessions.
+The repo is the workbench; Codex is the conversational interface; the CLI is
+the deterministic checker.
+
+## Default Path
+
+1. Read the target workspace files if they exist:
+   `brief.md`, `decisions.md`, `questions.md`, `spec.config.json`,
+   `sample.records.json`, and `review.md`.
+2. If the current repo is not yet an Airlock MCP specs repo, run or suggest:
+   `airlock-mcp init-repo`.
+   When helping create that repo from scratch, ask for the project or
+   organization name and suggest `<slug>-specs`; for example, `Home` becomes
+   `home-specs`. Reserve `airlock-specs` for the canonical reusable spec
+   library.
+   Public users should normally arrive through the single Airlock MCP install,
+   then ask Airlock to help build and use specs. Treat spec-building as a
+   capability inside that experience, not a second install.
+   If the user is in a blank specs project and provides the public Airlock MCP
+   GitHub URL, fetch or install Airlock MCP from that URL, run
+   `airlock-mcp init-repo` in the current project, then orient before creating
+   any workspace.
+   If the user opened the public `airlock-mcp` workbench repo as the entry
+   point, help them create a separate `<slug>-specs` project repo beside it.
+3. If no workspace exists, welcome the user and offer three starting paths
+   before creating files:
+   - brainstorm possible specs using the OODA loop
+   - start from a known process and create a blank workspace
+   - create a `posts` feedback loop where humans and agents can submit
+     requests, observations, and responses
+4. Create `posts` only when the user chooses a feedback loop, asks for humans
+   and agents to provide feedback, or explicitly requests the posts pattern.
+   If the user is unsure, offer OODA brainstorming first.
+5. Use `airlock-mcp import-spec <json-file> <name>` when starting from a
+   spec-library file, an exported `SPEC_CONFIG`, or an existing canonical config.
+6. Use `airlock-mcp clone <source-workspace> <name>` when creating a related
+   draft from an existing workspace. Treat clone like the old Streamlit UI:
+   preserve the shape but deliberately reset spec identity.
+7. Keep the draft small. Prefer one useful governed output over a large
+   speculative system.
+8. On later sessions, run `airlock-mcp list-workspaces` when the target draft
+   is not obvious.
+9. Run `airlock-mcp summary <workspace>` and
+   `airlock-mcp next <workspace>` before editing so
+   the current shape, sample count, access model, and local check status are
+   visible.
+10. Run `airlock-mcp check <workspace>` after changing draft config or sample
+   records.
+11. Keep `sample.records.json` as the agent-friendly authoring shape. Use
+   `airlock-mcp export-csv <workspace>` when the same examples need to be
+   reviewed or loaded through Airlock's CSV path.
+12. Use `airlock-mcp rename`, `archive`, and `restore` when organizing
+   workspaces so spec identity changes remain deliberate.
+13. Use `airlock-mcp render-sql <workspace>` only as a validate-only review
+   artifact. Installed Airlock validation remains authoritative.
+
+## Spec Design Questions
+
+Resolve these in order, and write the answers into `decisions.md`:
+
+1. What is one row about?
+2. What systems, users, files, events, or reference data must be observed before
+   a decision can be made?
+3. What decision will the spec support?
+4. What action follows that decision?
+5. Must the action be human-done, agent-assisted, or automated?
+6. What durable identifiers survive retries and reloads?
+7. What business event timestamps differ from Airlock load time?
+8. What evidence belongs as Airlock attachments?
+9. Which facts must be typed columns because people will filter, join, audit,
+   aggregate, or report on them?
+10. Which optional context can live in a validated `variant` field?
+11. Who submits, reviews, reads, delegates, and owns the process?
+
+## OODA Loop
+
+Use the observe-orient-decide-act loop as the product frame:
+
+- Observe: source systems, human signals, files, screenshots, exports, APIs,
+  reference specs, and prior Airlock outputs.
+- Orient: row grain, field types, access model, evidence, workflow, references,
+  expectations, and risk.
+- Decide: the smallest governed output worth creating now.
+- Act: validate locally, create in Airlock, collect real records, then extend or
+  add the next spec based on feedback.
+
+## Pattern Guidance
+
+Read only the relevant pattern files:
+
+- `patterns/starter-posts/` when the user needs a first feedback loop.
+- `patterns/guest-access/` when isolation or sharing is the hard part.
+- `patterns/spec-types/` when choosing observation, commitment,
+  reconciliation, or reference/master-data shape.
+- `docs/workflows.md` when the user asks how create, import, clone, check, or
+  render-SQL fit together.
+- `docs/architecture.md` when changing the CLI architecture.
+
+When adapting a pattern, report the source pattern, what changed, and which
+human decisions remain.
+
+## Airlock Boundaries
+
+- Local checks are not Airlock authority.
+- Installed Airlock procedures remain the execution contract.
+- Do not write directly to Airlock-owned tables, stages, generated views, or
+  generated tables.
+- Do not put Airlock workflow state, reviewer comments, approval status, or
+  pushback notes into submitted payload columns unless they are true upstream
+  facts from another system.
+- Use attachments for screenshots, receipts, PDFs, exports, and other evidence
+  files. Store only evidence metadata in payload fields.
+- Airlock MCP is the single installed interface for agents. This workbench helps
+  build specs; installed Airlock remains the authority for validating, creating,
+  loading, reading, and push/pull workflows through specs.

package/.agents/skills/airlock-mcp/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Airlock MCP"
+  short_description: "Draft and review Airlock specs with Codex."
+  default_prompt: "Use $airlock-mcp to help me draft a small Airlock spec, choose a starting pattern, and check the local workspace."

package/LICENSE

@@ -0,0 +1,187 @@
+Apache License
+Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+Copyright 2026 Reunion Studio
+
+TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+1. Definitions.
+
+"License" shall mean the terms and conditions for use, reproduction, and
+distribution as defined by Sections 1 through 9 of this document.
+
+"Licensor" shall mean the copyright owner or entity authorized by the copyright
+owner that is granting the License.
+
+"Legal Entity" shall mean the union of the acting entity and all other entities
+that control, are controlled by, or are under common control with that entity.
+For the purposes of this definition, "control" means (i) the power, direct or
+indirect, to cause the direction or management of such entity, whether by
+contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the
+outstanding shares, or (iii) beneficial ownership of such entity.
+
+"You" (or "Your") shall mean an individual or Legal Entity exercising
+permissions granted by this License.
+
+"Source" form shall mean the preferred form for making modifications, including
+but not limited to software source code, documentation source, and configuration
+files.
+
+"Object" form shall mean any form resulting from mechanical transformation or
+translation of a Source form, including but not limited to compiled object code,
+generated documentation, and conversions to other media types.
+
+"Work" shall mean the work of authorship, whether in Source or Object form,
+made available under the License, as indicated by a copyright notice that is
+included in or attached to the work (an example is provided in the Appendix
+below).
+
+"Derivative Works" shall mean any work, whether in Source or Object form, that
+is based on (or derived from) the Work and for which the editorial revisions,
+annotations, elaborations, or other modifications represent, as a whole, an
+original work of authorship. For the purposes of this License, Derivative Works
+shall not include works that remain separable from, or merely link (or bind by
+name) to the interfaces of, the Work and Derivative Works thereof.
+
+"Contribution" shall mean any work of authorship, including the original version
+of the Work and any modifications or additions to that Work or Derivative Works
+thereof, that is intentionally submitted to Licensor for inclusion in the Work
+by the copyright owner or by an individual or Legal Entity authorized to submit
+on behalf of the copyright owner. For the purposes of this definition,
+"submitted" means any form of electronic, verbal, or written communication sent
+to the Licensor or its representatives, including but not limited to
+communication on electronic mailing lists, source code control systems, and
+issue tracking systems that are managed by, or on behalf of, the Licensor for
+the purpose of discussing and improving the Work, but excluding communication
+that is conspicuously marked or otherwise designated in writing by the copyright
+owner as "Not a Contribution."
+
+"Contributor" shall mean Licensor and any individual or Legal Entity on behalf
+of whom a Contribution has been received by Licensor and subsequently
+incorporated within the Work.
+
+2. Grant of Copyright License. Subject to the terms and conditions of this
+License, each Contributor hereby grants to You a perpetual, worldwide,
+non-exclusive, no-charge, royalty-free, irrevocable copyright license to
+reproduce, prepare Derivative Works of, publicly display, publicly perform,
+sublicense, and distribute the Work and such Derivative Works in Source or
+Object form.
+
+3. Grant of Patent License. Subject to the terms and conditions of this License,
+each Contributor hereby grants to You a perpetual, worldwide, non-exclusive,
+no-charge, royalty-free, irrevocable (except as stated in this section) patent
+license to make, have made, use, offer to sell, sell, import, and otherwise
+transfer the Work, where such license applies only to those patent claims
+licensable by such Contributor that are necessarily infringed by their
+Contribution(s) alone or by combination of their Contribution(s) with the Work
+to which such Contribution(s) was submitted. If You institute patent litigation
+against any entity (including a cross-claim or counterclaim in a lawsuit)
+alleging that the Work or a Contribution incorporated within the Work
+constitutes direct or contributory patent infringement, then any patent licenses
+granted to You under this License for that Work shall terminate as of the date
+such litigation is filed.
+
+4. Redistribution. You may reproduce and distribute copies of the Work or
+Derivative Works thereof in any medium, with or without modifications, and in
+Source or Object form, provided that You meet the following conditions:
+
+   (a) You must give any other recipients of the Work or Derivative Works a copy
+       of this License; and
+
+   (b) You must cause any modified files to carry prominent notices stating that
+       You changed the files; and
+
+   (c) You must retain, in the Source form of any Derivative Works that You
+       distribute, all copyright, patent, trademark, and attribution notices from
+       the Source form of the Work, excluding those notices that do not pertain
+       to any part of the Derivative Works; and
+
+   (d) If the Work includes a "NOTICE" text file as part of its distribution,
+       then any Derivative Works that You distribute must include a readable copy
+       of the attribution notices contained within such NOTICE file, excluding
+       those notices that do not pertain to any part of the Derivative Works, in
+       at least one of the following places: within a NOTICE text file
+       distributed as part of the Derivative Works; within the Source form or
+       documentation, if provided along with the Derivative Works; or, within a
+       display generated by the Derivative Works, if and wherever such
+       third-party notices normally appear. The contents of the NOTICE file are
+       for informational purposes only and do not modify the License. You may add
+       Your own attribution notices within Derivative Works that You distribute,
+       alongside or as an addendum to the NOTICE text from the Work, provided
+       that such additional attribution notices cannot be construed as modifying
+       the License.
+
+   You may add Your own copyright statement to Your modifications and may
+   provide additional or different license terms and conditions for use,
+   reproduction, or distribution of Your modifications, or for any such
+   Derivative Works as a whole, provided Your use, reproduction, and distribution
+   of the Work otherwise complies with the conditions stated in this License.
+
+5. Submission of Contributions. Unless You explicitly state otherwise, any
+Contribution intentionally submitted for inclusion in the Work by You to the
+Licensor shall be under the terms and conditions of this License, without any
+additional terms or conditions. Notwithstanding the above, nothing herein shall
+supersede or modify the terms of any separate license agreement you may have
+executed with Licensor regarding such Contributions.
+
+6. Trademarks. This License does not grant permission to use the trade names,
+trademarks, service marks, or product names of the Licensor, except as required
+for reasonable and customary use in describing the origin of the Work and
+reproducing the content of the NOTICE file.
+
+7. Disclaimer of Warranty. Unless required by applicable law or agreed to in
+writing, Licensor provides the Work (and each Contributor provides its
+Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied, including, without limitation, any warranties or
+conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+PARTICULAR PURPOSE. You are solely responsible for determining the
+appropriateness of using or redistributing the Work and assume any risks
+associated with Your exercise of permissions under this License.
+
+8. Limitation of Liability. In no event and under no legal theory, whether in
+tort (including negligence), contract, or otherwise, unless required by
+applicable law (such as deliberate and grossly negligent acts) or agreed to in
+writing, shall any Contributor be liable to You for damages, including any
+direct, indirect, special, incidental, or consequential damages of any character
+arising as a result of this License or out of the use or inability to use the
+Work (including but not limited to damages for loss of goodwill, work stoppage,
+computer failure or malfunction, or any and all other commercial damages or
+losses), even if such Contributor has been advised of the possibility of such
+damages.
+
+9. Accepting Warranty or Additional Liability. While redistributing the Work or
+Derivative Works thereof, You may choose to offer, and charge a fee for,
+acceptance of support, warranty, indemnity, or other liability obligations
+and/or rights consistent with this License. However, in accepting such
+obligations, You may act only on Your own behalf and on Your sole
+responsibility, not on behalf of any other Contributor, and only if You agree to
+indemnify, defend, and hold each Contributor harmless for any liability incurred
+by, or claims asserted against, such Contributor by reason of your accepting any
+such warranty or additional liability.
+
+END OF TERMS AND CONDITIONS
+
+APPENDIX: How to apply the Apache License to your work.
+
+To apply the Apache License to your work, attach the following boilerplate
+notice, with the fields enclosed by brackets "[]" replaced with your own
+identifying information. (Don't include the brackets!) The text should be
+enclosed in the appropriate comment syntax for the file format. We also
+recommend that a file or class name and description of purpose be included on
+the same "printed page" as the copyright notice for easier identification within
+third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/README.md

@@ -0,0 +1,126 @@
+# Airlock MCP
+
+Airlock MCP is the single installed interface for AI agents working with
+Airlock.
+
+It covers the full Airlock loop:
+
+- build specs with the bundled spec-building workbench
+- use specs to pull and push governed data with the Airlock Star capability
+- validate, create, and revise specs against installed Airlock
+- capture real use cases and improvements so specs get better over time
+
+Spec building is not a second thing users install. It is bundled inside
+Airlock MCP.
+
+Airlock Star is not a second thing users install either. It is the capability
+inside Airlock MCP for working through real Airlock use cases,
+pulling and pushing data through specs, reading outputs, and turning experience
+back into better specs.
+
+## Install
+
+Dogfood directly from GitHub:
+
+```bash
+npx -y github:reunionstudio/airlock-mcp install --package github:reunionstudio/airlock-mcp
+```
+
+After the npm package is published, use:
+
+```bash
+npx @reunionstudio/airlock-mcp install
+```
+
+Today this package is a small installer and MCP launcher. For Codex, install
+registers a local stdio server with:
+
+```bash
+codex mcp add airlock -- npx -y @reunionstudio/airlock-mcp server
+```
+
+The GitHub dogfood command registers:
+
+```bash
+codex mcp add airlock -- npx -y github:reunionstudio/airlock-mcp server
+```
+
+The server exposes bootstrap guidance for starting a specs repo and entering
+the bundled spec-building workbench or the Airlock Star use-and-improve
+capability.
+
+This install shape uses Node because `npx` runs npm package binaries. MCP itself
+does not require Node. Once Airlock MCP does real operational work, such as
+validating specs, loading records, handling attachments, reading outputs, and
+coordinating push/pull workflows, the production server should likely be Rust
+with `rmcp`: single binary, predictable memory and latency, typed tool
+contracts, and no Node/Python runtime for the long-running process. The npm
+package can remain the friendly installer.
+
+For stdio MCP, stdout is protocol-only. Logs and diagnostics must go to stderr.
+
+## Test
+
+```bash
+npm test
+node -c bin/airlock-mcp.mjs
+python3 -m json.tool package.json
+PYTHONPATH=src python3 -m unittest discover
+PYTHONPATH=src python3 -m airlock_mcp doctor
+```
+
+The smoke test verifies install dry-run output and the stdio MCP handshake for
+`initialize`, `tools/list`, `prompts/list`, `resources/list`, prompt reads,
+tool calls, resource reads, unknown methods, malformed input, and install
+argument validation. It also exercises the bundled Python workbench through MCP
+tool calls against a temporary specs repo.
+
+## MCP Tools
+
+The server exposes orientation plus local spec-building tools:
+
+- `airlock_start`: return setup guidance for a project.
+- `airlock_doctor`: verify bundled workbench assets.
+- `airlock_init_repo`: bootstrap a blank specs repo.
+- `airlock_list_patterns` and `airlock_show_pattern`: inspect starter patterns.
+- `airlock_init_workspace`: create a workspace from `blank` or `posts`.
+- `airlock_list_workspaces`: inspect active or archived drafts.
+- `airlock_check_workspace`, `airlock_summary`, and `airlock_next`: validate and re-enter a draft.
+- `airlock_export_csv`: render `sample.records.json` as Airlock-ready CSV.
+- `airlock_render_sql`: render validate-only Airlock admin SQL.
+
+Workbench tools default to the MCP server working directory and accept an
+optional `cwd` when an agent needs to target a specific specs repo. They launch
+the bundled Python workbench by argv array, not through a shell. Python 3 is
+required for those workbench tools; `airlock_start`, prompts, resources, and
+installer behavior remain pure Node.
+
+## Repo Layout
+
+- `bin/airlock-mcp.mjs`: executable entry point.
+- `src/cli.mjs`: argument parsing and command dispatch.
+- `src/install.mjs`: Codex MCP registration.
+- `src/mcp.mjs`: JSON-RPC handlers and stdio loop.
+- `src/text.mjs`: prompts and user-facing guidance.
+- `src/airlock_mcp/`: Python spec-building workbench and local checker.
+- `.agents/skills/airlock-mcp/`: repo-scoped Codex skill for spec drafting.
+- `patterns/`: reusable spec and access patterns.
+- `workspaces/`: spec workspace template files.
+- `schemas/`: documented draft shapes.
+- `docs/architecture.md`: architecture and runtime boundaries.
+- `SECURITY.md`: security rules for current and future tools.
+
+The intended user flow is:
+
+1. Run `npx @reunionstudio/airlock-mcp install` once for the agent environment.
+2. Open Codex.
+3. Create a blank project repo named for the org or project, such as
+   `home-specs`.
+4. Ask Codex to use Airlock MCP to help build specs and use specs with
+   Airlock Star.
+5. Let Airlock MCP bootstrap the project, welcome the user, and offer the next
+   useful path before creating the first workspace.
+
+The first workspace should not be created automatically. The spec-building
+workbench should offer OODA brainstorming, a known-process draft, or a shared
+`posts` feedback loop.

package/SECURITY.md

@@ -0,0 +1,31 @@
+# Security
+
+Airlock MCP is an agent-facing connector. Treat every tool as a governed
+operation surface.
+
+## Current Bootstrap Server
+
+- Uses stdio transport only.
+- Writes only JSON-RPC messages to stdout.
+- Sends diagnostics and install errors to stderr.
+- Uses `spawnSync` without a shell for Codex registration.
+- Validates MCP server names before passing them to `codex mcp add`.
+- Passes npm or GitHub package specs as argv entries, never through a shell.
+- Rejects package specs with whitespace or control characters.
+- Exposes guidance only; it does not read local secrets, call Snowflake, mutate
+  files, or contact network services.
+
+## Production Rules
+
+- Validate all user-supplied paths and identifiers.
+- Restrict local file access to the active specs repo unless the user grants
+  broader access.
+- Treat installed Airlock as the authority for validation, mutation, workflow,
+  attachments, and governed data movement.
+- Keep Airlock lifecycle state, reviewer state, and approval workflow separate
+  from submitted business payloads unless they are true upstream facts.
+- For stdio MCP, never log to stdout.
+- For future Streamable HTTP MCP, bind local servers to localhost, validate
+  `Origin`, and require proper authentication.
+
+Report security issues privately to the Reunion Studio maintainers.

package/bin/airlock-mcp.mjs

@@ -0,0 +1,5 @@
+#!/usr/bin/env node
+
+import { main } from "../src/cli.mjs";
+
+process.exitCode = await main();

package/docs/architecture.md

@@ -0,0 +1,82 @@
+# Architecture
+
+Airlock MCP is the single installed interface for agents working with Airlock.
+The public command should stay simple:
+
+```bash
+npx @reunionstudio/airlock-mcp install
+```
+
+Before npm publication, the same shape can run from GitHub:
+
+```bash
+npx -y github:reunionstudio/airlock-mcp install --package github:reunionstudio/airlock-mcp
+```
+
+The current package is a dependency-light Node installer and bootstrap stdio MCP
+server. It gives agents a standard way to start the Airlock loop while the
+heavier operational tools mature.
+
+## Boundaries
+
+- `bin/airlock-mcp.mjs`: executable entry point only.
+- `src/cli.mjs`: argument parsing and command dispatch.
+- `src/install.mjs`: Codex MCP registration command construction and execution.
+- `src/mcp.mjs`: JSON-RPC request handling and stdio transport loop.
+- `src/text.mjs`: product language, prompts, repo naming, and guidance text.
+- `test/smoke.mjs`: executable smoke and protocol tests.
+
+The spec-building workbench lives in this repo under `src/airlock_mcp`,
+`patterns`, `workspaces`, `schemas`, and `.agents/skills/airlock-mcp`.
+Airlock Star is the use-and-improve capability inside Airlock MCP: real use
+cases, governed pull/push through specs, output review, and improvement capture.
+It is also not a second install.
+
+## MCP Surface
+
+The bootstrap server exposes:
+
+- prompt: `airlock-start`
+- resource: `airlock://getting-started`
+- orientation tool: `airlock_start`
+- workbench tools: `airlock_doctor`, `airlock_init_repo`,
+  `airlock_list_patterns`, `airlock_show_pattern`, `airlock_init_workspace`,
+  `airlock_list_workspaces`, `airlock_check_workspace`, `airlock_summary`,
+  `airlock_next`, `airlock_export_csv`, and `airlock_render_sql`
+
+These give the agent enough context to start a blank `<project>-specs` repo,
+enter the spec-building workbench when specs need drafting, enter Star when
+specs need to be used or improved, and avoid creating a first workspace until
+the user chooses a path.
+
+Workbench tools call the bundled Python package with argument arrays and a
+controlled `PYTHONPATH`. They do not expose update commands over MCP. Tool
+errors are returned as MCP tool results with `isError` so stdout remains valid
+JSON-RPC.
+
+## Stdio Rules
+
+MCP stdio messages are newline-delimited JSON-RPC. The server must write only
+valid MCP messages to stdout. Logs and diagnostics belong on stderr.
+
+## Install Rules
+
+For Codex, install registers:
+
+```bash
+codex mcp add airlock -- npx -y @reunionstudio/airlock-mcp server
+```
+
+The installer uses argument arrays, not shell strings, for execution. Server
+names are allowlisted to letters, numbers, dot, underscore, and hyphen. Package
+specs are passed as argv entries, never through a shell, and are rejected if they
+contain control characters.
+
+## Runtime Direction
+
+Keep the Node package as the friendly installer and bootstrap launcher.
+
+Prefer Rust with `rmcp` for the production Airlock MCP server once tools do
+real operational work: validating specs, loading records, reading outputs,
+handling attachments, coordinating push/pull workflows, or serving multiple
+agents concurrently.

package/docs/install-surface.md

@@ -0,0 +1,112 @@
+# Install Surface
+
+Airlock should offer a familiar agent-connector install surface without making
+the implementation more clever than the user journey requires.
+
+## Recommendation
+
+Use an MCP-style public front door:
+
+```bash
+npx @reunionstudio/airlock-mcp install
+```
+
+Airlock MCP is the single installed interface for agents working with Airlock.
+Then the user opens Codex, creates a blank `<project>-specs` repo, and starts
+chatting with Airlock. Airlock MCP should cover building specs, using specs to
+pull and push governed data, and capturing improvements from real use cases.
+
+The install command is not the spec workspace. It is the connector/setup entry
+point. The specs repo is still the durable memory.
+
+The connector package and MCP server live in `reunionstudio/airlock-mcp`.
+This workbench provides the spec-building implementation inside that one
+installed Airlock MCP experience.
+
+For Codex, the install command should register a local stdio MCP server using
+Codex's built-in MCP manager:
+
+```bash
+codex mcp add airlock -- npx -y @reunionstudio/airlock-mcp server
+```
+
+## What `npx` Means
+
+`npx` is the npm package runner. It runs a command from a local or remote npm
+package. If the requested package is not already available locally, npm can
+fetch it into its cache and put that package's executable on `PATH` for the
+command.
+
+That means `npx @reunionstudio/airlock-mcp install` requires Node/npm on the
+user's machine, but does not require them to clone this workbench, install a
+separate spec-building tool, or install a global binary by hand.
+
+It is common in MCP examples because many local MCP servers and installers are
+distributed as npm packages, and developers often already have Node tooling.
+It is not required by MCP.
+
+## MCP Is Runtime-Agnostic
+
+MCP is a protocol, not a Node framework. The server can be written in Node,
+Python, Rust, Go, Java, C#, or another language as long as it speaks the
+protocol over a supported transport.
+
+The standard transports to care about first are:
+
+- stdio for local agent-launched servers
+- Streamable HTTP for hosted or longer-running servers
+
+## Alternatives
+
+Viable install surfaces include:
+
+- `npx @reunionstudio/airlock-mcp install`: best familiar first impression for agent users
+- `uvx airlock-mcp` or `pipx install ...`: useful for workbench development
+  and dogfooding, not the public primary path
+- Homebrew: good for macOS developer installs
+- a signed Rust binary: best for single-file distribution later
+- Docker: useful for controlled server deployments, but heavy for spec drafting
+- hosted Streamable HTTP MCP: useful when Airlock becomes a remote service
+
+## Runtime Choice
+
+Use Node for the thin public installer and launcher if we want
+`npx @reunionstudio/airlock-mcp install`, because `npx` is specifically an npm/Node
+distribution path. The Node package should stay small: register the MCP server,
+print the next Codex steps, and provide a bootstrap stdio server while the
+runtime is still light.
+
+Keep Airlock MCP's drafting CLI in Python for now. The current work is
+Markdown, JSON, CSV, pattern loading, and local validation. Product fit and
+workflow clarity matter more than raw performance.
+
+Prefer Rust with `rmcp` for the production Airlock MCP server once the server
+does real work beyond bootstrap guidance, especially Snowflake/Airlock calls,
+workspace scanning, policy checks, loading records, reading outputs, handling
+attachments, push/pull workflows, or multi-agent traffic. The Rust guidance we
+care about:
+
+- a single signed binary
+- stronger local distribution ergonomics
+- predictable memory and latency for concurrent agents
+- typed tool contracts and generated JSON schemas
+- no Node or Python runtime dependency for the long-running server
+- stricter supply-chain or runtime constraints
+
+For stdio MCP servers, stdout is the JSON-RPC protocol channel. Logs, tracing,
+and diagnostics must go to stderr or the client can disconnect. Integration
+tests should send raw JSON-RPC `initialize` and `tools/list` messages to the
+server binary and parse the responses.
+
+Do not rewrite the spec-building logic in Rust just to look more performant.
+If we want Rust, use it first as a distribution wrapper or future MCP server,
+then port core spec-building logic only when real performance, security, or
+packaging pressure appears.
+
+The first release should optimize the user journey:
+
+1. install connector
+2. create blank `<project>-specs` Codex project
+3. bootstrap the spec-building capability when specs need drafting
+4. help the user use specs to validate, load, read, push, and pull data
+5. create the first workspace only after the user chooses a path