coulomb/email-connect
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: retain provider setup delivery owner intake
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a15374-f59f-7a31-86d2-d23b5d2ed181
This commit is contained in:
tegwick 2026-10-19 13:16:55 +02:00
parent f77e2333af
commit 994db7d040
1 changed files with 55 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

55
intakes/EMAIL-IN-0001-provider-setup-link-delivery-contract.md Normal file
View file

@ -0,0 +1,55 @@
---
id: EMAIL-IN-0001
kind: intake
title: "Support the provider-owned single-use password-setup delivery handoff"
status: open
flavor: implementation
origin: cross-repo
origin_ref: USER-WP-0035-T02
priority: high
owner: email-connect
repo: email-connect
requested_by: user-engine
created: "2026-10-11"
updated: "2026-10-11"
related: [NET-IN-0005, EMAIL-WP-0004, EMAIL-WP-0008]
---
USER-WP-0035-T02 needs delivery of the identity-provisioner's setup link to the
intended person. EMAIL-WP-0004 supplies the mail service and EMAIL-WP-0008 supplies
scoped invitation/verification callers. They do not supply this template:
`callers.TEMPLATES` and `transactional.ALLOWED_EVENTS` permit only
`family_member.invited` and `family_invitation.resent`; `/v1/send` renders an
invitation URL. Neither registration-verification mail nor Authelia reset SMTP
is this provider setup grant. Do not reinterpret an invitation event to bypass
that class boundary.
Prepare an owner-supported fixed template and recipient-bound transport contract
with the NetKingdom issuer (NET-IN-0005), then return its exact implementation
work record and public capability/adapter contract. This is owner preparation,
not a request for another founder choice or a founder-ready command. Keep the
current caller/template/binding scope unchanged until the owner has reviewed
its precise extension; use existing custody/delivery interfaces rather than a
shared administrative token.
The contract must bind the authenticated caller, intended tenant/client,
provider identity and authoritative recipient, provider issue/expiry and stable
request identity. Prefer issuer-to-mail delivery with an opaque receipt to User
Engine. A secret setup URL/handle may cross only the reviewed delivery boundary;
it must never enter user-engine's domain outbox, event bus, work records,
receipts, prompts, logs, arbitrary subjects/bodies or caller-supplied redirects.
Fixed destination/origin admission, payload bounds and redirect refusal belong
to that contract. Do not assume the existing invitation template accepts it.
Reuse the existing suppression/idempotency/uncertain-outcome behavior. Distinguish
confirmed non-acceptance, accepted, uncertain and terminal rejection without
reissuing a grant or duplicating mail on timeout/restart. Emit opaque non-secret
request/provider references and the exact evidence ceiling. SMTP acceptance,
mailbox delivery, intended-person acknowledgement and password completion remain
separate observations; none supplies authorization or identity proof by itself.
Acceptance needs synthetic failure/expiry/replay/recipient-mismatch/restart
checks followed by an explicitly scoped owner-reviewed live send and private
intended-person receipt. No live recipient, message, token or grant was used in
this intake. Return a workplan/task ID before USER-WP-0035-T02 replaces its
`blocked_on: message-from:email-connect` qualifier with exact dependencies.