Mode contract v0.1 final (MAS-WP-0014 finished)

Founder decision after the independent JS email side. Draft markers
removed (bundle, address spec v0.2 section 7.1, reuse surface), CHANGELOG
v0.1 with MCP-1..6 and known limits. SCOPE: all workplans but MAS-WP-0007
finished.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 5787@bnt-lap001
Assistant-Session: 5db26b82-138b-40cc-9856-4d5eb0f752fd

SCOPE.md

@@ -7,10 +7,9 @@ Reference implementation and spec workbench for Mail Address Semantics
 framework. Contents: parser, statute discovery, pure policy, generator,
 CLI, mail gateway, reference ticket service, a tested Postfix integration
 profile, and the mode contract with an email side that works as master or
-slave. It implements address spec v0.1.1 and v0.2 (final), and mode
-contract v0.1 (draft). A second, independent implementation in
-JavaScript (`impl/js/`) validates v0.2 and the master side of the mode
-contract.
+slave. It implements address spec v0.1.1 and v0.2, and mode contract
+v0.1; all are final. A second, independent implementation in JavaScript
+(`impl/js/`) validates v0.2 and both sides of the mode contract.
 
 ## Core Idea
 
@@ -86,20 +85,18 @@ delivery stays external.
 - Status: active. The reference experiment (MAS-WP-0002) passed its
   decision gate on 2026-10-18; the findings are in
   `docs/experiment-review.md`.
-- Finished: MAS-WP-0001 to 0006 and 0008 to 0013. That covers v0.2,
-  which is final; the mode contract with authentication, one outbound
-  path and harness-independent flows; and the second implementation. Postfix profile, v0.1.1
-  errata, v0.2 draft, address composer, v0.2 conformance cases, and the
-  mode contract with its reference implementation.
-- Open: MAS-WP-0007 (retire the live MX; backlog, kept by decision) and
-  MAS-WP-0014 (finalize mode contract v0.1; waits for an independent email
-  side).
+- Finished: MAS-WP-0001 to 0006 and 0008 to 0014. That covers the
+  Postfix profile, the v0.1.1 errata, v0.2 (final), the address composer,
+  the mode contract v0.1 (final) with authentication, one outbound path
+  and bundle-only flows, and the second implementation (`impl/js/`, both
+  specs, both contract sides).
+- Open: MAS-WP-0007 (retire the live MX; backlog, kept by decision).
 - v0.2 is final (founder, 2026-10-19, after MAS-WP-0009). Mode contract
-  v0.1 stays a draft.
+  v0.1 is final too (founder, 2026-10-19, after MAS-WP-0014: independent
+  JS email side; MCP-1 to MCP-6).
 - P2 is decided: `!MODE` requests a handoff (founder, 2026-10-19; SCP-8,
-  v0.2 §7.1). The mode contract v0.1 draft and the reference
-  implementation are done (MAS-WP-0010); `mas test` runs the contract
-  corpus.
+  v0.2 §7.1). The mode contract and its reference implementation are
+  done (MAS-WP-0010); `mas test` runs the contract corpus.
 - The live MX runs image `mas-live:v0.2-480e69a` (redeployed 2026-10-19)
   and is kept up by founder decision (MAS-WP-0007 stays in backlog).
   The deployment with MAS-WP-0012 (one outbound path) is recorded in

docs/reuse-surface.md

@@ -9,8 +9,8 @@ how stable each part is.
 
 | Part | Where | Stability |
 |---|---|---|
-| MAS address spec | `mas-v0.1-spec/` (v0.1.1), `mas-v0.2-spec/` (draft) | v0.1.1 stable. v0.2 draft until a second implementation passes its corpus (MAS-WP-0009) |
-| Mode contract | `mas-modes-v0.1-spec/` | v0.1 draft. Changes are versioned; messages carry `mas_modes_version` |
+| MAS address spec | `mas-v0.1-spec/` (v0.1.1), `mas-v0.2-spec/` | v0.1.1 and v0.2 final (v0.2: 2026-10-19, two independent implementations) |
+| Mode contract | `mas-modes-v0.1-spec/` | v0.1 final (2026-10-19), with two independent email sides. Changes are versioned; messages carry `mas_modes_version` |
 | Gateway event | `mas-modes-v0.1-spec/schema/mas-event-v0.1.schema.json` | v0.1. Events carry `mas_event_version` |
 | Conformance corpora | the bundles' `conformance/` | Normative for their version. Consume them unchanged |
 | `mas_core` | parse (no I/O), discover (exact host), resolve (pure), generate / `for_destination` | Python reference library |

mas-modes-v0.1-spec/CHANGELOG.md

@@ -0,0 +1,29 @@
+# MAS mode contract changelog
+
+## v0.1 (2026-10-19)
+
+Declared final by the founder after the second, independent email side
+(MAS-WP-0014). `impl/js/src/email.mjs`, written from CONTRACT.md and
+`conformance/FLOWS.md` alone, passes all 22 flows. With the independent JS
+outside master it passes the 12 slave-setup flows with no Python contract
+party.
+
+Built in MAS-WP-0010, 0011 and 0013: roles, the status machine, message
+types, principle 10 with one send cap that holds over it (MAS-WP-0012),
+peer authentication (§7), and bundle-only conformance flows.
+
+Folded in before release (`docs/mode-contract-proposals.md`):
+
+- MCP-1: a new email-mastered case is acknowledged by mail (§3.1.1).
+- MCP-2: details are `Field: value` lines; questions list `Field: ...`
+  (§3.1.4).
+- MCP-3: a resume mail names the terminal status and its reason or detail
+  (§3.1.3).
+- MCP-4: `case.key` is chosen by email and opaque to others (§1).
+- MCP-5: error table (§5.1).
+- MCP-6: what a blocked or forwarded transfer reports and relays (§3.2.4).
+- Flow a-008 (a master commands only its own resource types).
+
+Known limits, not gates: neither email side has run against a real CMS or
+telephony system yet. Evidence from such integrations goes into the next
+version as MCP proposals.

mas-modes-v0.1-spec/CONTRACT.md

@@ -1,4 +1,4 @@
-# MAS mode contract v0.1 (draft)
+# MAS mode contract v0.1
 
 How email hands a conversation to another communication mode, and how
 email works inside a control flow it does not own. The bundle is

mas-modes-v0.1-spec/README.md

@@ -1,4 +1,8 @@
-# MAS mode contract v0.1 (draft): specification bundle
+# MAS mode contract v0.1: specification bundle
+
+Final as of 2026-10-19. Two independent email sides pass its flows
+unchanged: `mas_modes.email_mode` (Python) and `impl/js/src/email.mjs`
+(JavaScript). See `CHANGELOG.md`.
 
 How email hands a case to another communication mode, and how email works
 as one element of a control flow it does not own. It is versioned

mas-v0.2-spec/SPECIFICATION.md

@@ -322,7 +322,7 @@ A receiver that acts on an interaction request treats it as a request to
 hand the conversation over to `MODE`. What can happen to that request
 (negotiation, scheduling, completion, failure, refusal, timeout), and who
 owns the conversation meanwhile, is defined by the MAS mode contract. The
-contract is versioned separately (`mas-modes-v0.1-spec/`, draft). Email
+contract is versioned separately (`mas-modes-v0.1-spec/`). Email
 remains the durable thread when it is the master. The handoff stays a
 request: refusal is a normal outcome, and the address grants nothing.
 

workplans/MAS-WP-0014-finalize-mode-contract.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Finalize mode contract v0.1: an independent email side"
 domain: communication
 repo: mail-address-semantics
-status: active
+status: finished
 owner: claude
 topic_slug: coulomb-social
 created: "2026-10-19"
@@ -41,7 +41,7 @@ the findings into CONTRACT.md as proposals, as SCP-9 did for v0.2.
 
 ```task
 id: MAS-WP-0014-T02
-status: progress
+status: done
 priority: low
 state_hub_task_id: "63e4028d-ff57-5855-92d5-fa6ece0382c2"
 ```
@@ -77,3 +77,12 @@ final. Then remove "draft" from the bundle and v0.2 §7.1.
   pass it, and it catches the mutation.
 - **Tests.** `tests/test_js_impl.py`: JS email, all flows; JS email with JS
   master. `mas test`: mode corpus 196/196.
+
+## Outcome of T02 (2026-10-19)
+
+**Founder decision: mode contract v0.1 is final.** "Draft" is removed from
+the bundle and from address spec v0.2 §7.1. `mas-modes-v0.1-spec/CHANGELOG.md`
+records v0.1, MCP-1 to MCP-6, flow a-008 and the known limits: no real CMS
+or telephony integration yet, and the JS side checks message shape by
+hand. Evidence from real integrations goes into the next contract version
+as MCP proposals; it does not gate v0.1.