INTENT.md: phase 2 (experiment passed, spec workbench role, auto-reply principle, open P2 question)

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

INTENT.md

@@ -1,6 +1,15 @@
 # MAS — Mail Address Semantics
 
-## Intent
+## Status
+
+**Phase 1 (reference experiment) passed** its decision gate on 2026-10-18
+(MAS-WP-0002, `docs/experiment-review.md`). All ten success criteria were
+met, including the live run through Gmail, Microsoft 365 and Postfix.
+**Phase 2** is described in *Phase 2 intent* below. The phase-1 sections
+are kept as the record of what was tested; where phase 2 changes them, it
+says so.
+
+## Intent (phase 1)
 
 Build the smallest practical implementation of **Mail Address Semantics (MAS) v0.1** that can prove whether the specification is useful in real email workflows.
 
@@ -265,6 +274,25 @@ No implementation work on price, reward, conditions, offers, contracts, or settl
 
 ---
 
+### 10. Auto-reply endpoints are gated and capped
+
+*(Added in phase 2, from the live run.)*
+
+An address that answers automatically, such as `ticket!callback@`, turns
+any forged `From:` into outbound mail to a third party. Any endpoint that
+replies automatically therefore:
+
+- replies only when the sender is authenticated (DMARC pass, read from
+  trusted `Authentication-Results`);
+- never replies to automated mail or to the null sender;
+- caps how much it can send in total.
+
+This is application policy, not MAS syntax. But a MAS deployment that
+leaves it out reflects mail at third parties, and the reference
+implementation must show how to avoid that.
+
+---
+
 ## Initial architecture
 
 The first repository should contain only the pieces needed for the experiment.
@@ -439,7 +467,10 @@ Later mail must not silently reopen or mutate the resource unless application po
 
 ---
 
-## Explicit non-goals
+## Explicit non-goals (phase 1)
+
+*Phase 2 removes the address composer and the MTA integration profile
+from this list (see Phase 2 intent). The rest still applies.*
 
 The initial implementation does not include:
 
@@ -477,6 +508,75 @@ The first experiment succeeds if:
 
 ---
 
+## Phase 2 intent
+
+Phase 1 showed that the convention works through ordinary infrastructure
+once the MTA is configured correctly, and that resource addressing is the
+strongest part of MAS. Phase 2 turns the experiment into a usable
+reference. It still stays narrow.
+
+### Role of this repository
+
+This repository is the **spec workbench** as well as the reference
+implementation. It maintains the normative bundles (`mas-v0.1-spec/` as
+v0.1.1 errata, and the `mas-v0.2-spec/` draft) and records every change as
+a proposal in `docs/spec-change-proposals.md`. Every spec change needs:
+
+- evidence from a test or a live run;
+- conformance fixtures in the bundle;
+- an implementation in `mas_core`.
+
+Implementation and spec move together. A version is declared final only
+after a second implementation or deployment has passed its corpus
+unchanged.
+
+### Goals
+
+1. **Adoptable integration.** A documented, tested MTA profile, so that
+   P2 addresses survive. Default Postfix drops them. Postfix is done; Exim
+   only on demand.
+2. **Forwarder-safe generation.** Provider forms refuse `=` and fold case.
+   The generator and `mas compose` emit the canonical form and, where the
+   statute allows it, a forwarder-safe form. When that form would be
+   misread, they refuse to emit it.
+3. **v0.2 to final.** Settle stand-ins, destination transforms and
+   `resource_id_case`. Finalize once an independent implementation
+   validates the corpus.
+4. **Safe reference behavior.** The reference service demonstrates
+   principle 10.
+
+### Open question: the value of interaction (P2)
+
+Phase 1 proved resource addressing strongly, and interaction only partly.
+`!callback` states the intent, but the service still has to ask for a
+number and a time. The link from the opaque intake target `ticket` to the
+resource type `ticket` exists only through a statute registry entry.
+Phase 2 must decide one of two things:
+
+- define "type intake" semantics, so that an opaque target naming a
+  declared resource type has a specified meaning; or
+- narrow P2 to a pure preference hint, and stop adding mechanism for it
+  (such as the `---` stand-in) until a use case needs it.
+
+### Still not in phase 2
+
+Other language implementations (except one used to validate v0.2), a
+policy daemon, a central registry, mail-client plugins, signed statutes,
+implicit parent inheritance, and economic semantics. A web composer is out
+until something asks for one.
+
+### Phase 2 is done when
+
+1. a fresh Postfix install, using only `integrations/postfix/`, delivers
+   the full corpus unchanged and refuses relaying;
+2. `mas compose` produces correct forms for every destination observed so
+   far, and refuses the rest;
+3. v0.2 is declared final, or is withdrawn with recorded reasons;
+4. the P2 question above is decided and recorded in the spec;
+5. the live test environment is retired, with its evidence archived.
+
+---
+
 ## Longer-term direction
 
 If the experiment validates the concept, MAS may later grow into: