Project Plan: Invitation Mail Server

Project Plan: Invitation Mail Server

Implementation plan derived from the Design and its settled Decision Log. The design is the single source of truth for what gets built (structural elements, behaviors, verification catalog, implementation artifacts); this plan sequences the work into phases, states their gates, and hosts the per-phase driving documents.

Phase Structure

Phase	Directory	Repository	Output
1 — Sending Library	1-sending-library/	common-module	lib/infra/email package (lifted + new classes), ConfigurationProvider binding; published release 13.2.0
2 — Partition Provisioning	2-partition-provisioning/	infrastructure	SystemEmailServer Pre-Deploy step, PartitionEmailStack extension, amm.sh wiring, drift checks; merged to main (not yet deployed)
3 — Operations Wiring	3-operations-wiring/	operations	13.2.0 adoption (lift re-imports), Helm secret projection, email {} block, internal system sender, dev smoke spec; merged to main
4 — Rollout & Release	4-rollout/	all + documentation	Partition-by-partition deployment (dev → {stage ∥ demo} → prod), end-to-end verification, current-system docs, project completion

Phase Dependencies

Phases 1 and 2 are independent and proceed in parallel. Phase 3’s code depends only on Phase 1’s published artifact; its dev verification (the BV-4-06 smoke, executed in Phase 4) additionally requires Phase 2 deployed to dev. Arrows follow the dependency convention (solid = artifact/contract dependency, green = deploy gate — a dependency on a deployed-and-verified state, per the planning workflow’s gate rule); dependents point at their dependencies.

Worktree Strategy

Single-agent project: one worktree per repository already exists under projects/invitation-mail-server-worktrees/ (common-module, infrastructure, operations, documentation), all on branch jmpicnic/invitation-mail-server. No task worktrees and no integration branch are needed — phases touch disjoint repositories and each repository produces exactly one PR from its worktree branch.

workspace changes (skills) are made directly in the workspace main clone per the continuous-improvement flow — no worktree.

Release Ordering

Per the release-lifecycle conventions, upstream merges before downstream:

1. common-module PR merges first → CI publishes 13.2.0 to GitHub Packages (gate for step 3). CHANGELOG model: direct-edit (make clqLint).
2. infrastructure PR merges independently (no artifact consumers) — CHANGELOG model: direct-edit (make lint). Merge does not deploy; deployment is Phase 4 operator work via amm.sh.
3. operations PR merges after 13.2.0 is published (its gradle/libs.versions.toml bump must resolve). CHANGELOG model: direct-edit (make clqLint).
4. documentation PRs: the design-phase PR (#140, open) and a completion PR at the end of Phase 4 (current-system pages, project status → completed). CHANGELOG model: PR-body.

Composite-build guard (applies to steps 1–3): before every operations or common-module commit, verify no stray includeBuild("../common-module") lands in settings.gradle.kts (git diff --cached | grep -iE 'includeBuild|/Users/|-worktrees').

Byproducts and Session Records

Each phase directory accrues byproducts/ (changelog draft, learnings, suggestions, skipped items, post-implementation specification deltas) and session/ records during implementation, per the implementation-task workflow.

Completion Checklist (project level)

• Phases 1–3 merged; 13.2.0 published; all repo CI green.
• Phase 4 rollout complete: all four partitions provisioned and verified; dev smoke (BV-4-06) has sent a real message.
• runtime-platform-drift green on its first post-rollout scheduled run.
• Current-system documentation updated (messaging capability, runtime/OAM email pages, secret inventory).
• Project documents set to status: completed; worktrees and local branches removed.
• Linear ticket resolved via the operations/final PR ## Closes (design chain-of-custody comments already posted).

References

• Goal · Design · Decision Log
• Email Integration phases — the parent project this plan’s conventions mirror

---

---

Copyright: (c) Arda Systems 2025-2026, All rights reserved