Proposal #1: Define v1.0 Go/No-Go Release Criteria with User Validation Gates

[guyghost]

📦 Release Change

Define a concrete set of go/no-go release criteria covering: all critical user journeys passing acceptance tests (#21 feeds this), crash-free rate threshold, core offline flow reliability, and a structured dogfooding pass by 3+ real users completing the full DRAFT→POLLING→CONFIRMED flow. Each criterion gets a binary pass/fail with owner and deadline.

Context

Wakeve is on release/1.0.0-store-submission branch. Phase 2 complete with 36/36 tests passing. Phase 3 partially complete (Auth, Calendar agents). Store review timelines are unpredictable. Proposal suggested by Product Strategist during round table.

---

Proposal #1 · Created: 2026-04-15T15:53:05.334Z · By: user

[guyghost]

🗳️ Deliberation Complete — ✅ APPROVED

Duration: 148.7s (parallel execution)

Metric	Result	Required
Participation	10/10 agents (100.0%)	60% quorum
Approval	18/18 weighted (1.0%)	55% threshold

Synthesis

Deliberation Synthesis

Vote Overview

• For: 10 agents (weighted: 18)
• Against: 0 agents (weighted: 0)
• Abstain: 0 agents

Consensus Points

All agents voted for this proposal — full consensus.

Agent Analyses

Product Strategist (Business strategy and user value)

Vision Statement

Before Wakeve ships to app stores, we need a safety net that automatically enforces our architectural contract. An FC&IS fitness test suite transforms our implicit architectural agreements into explicit, CI-enforced guarantees — ensuring that the 6+ phases of organic growth haven't silently eroded the boundaries that keep the app stable, testable, and crash-resistant at scale.

Objectives

• Achieve 100% automated detection of FC&IS boundary violations on the release/1.0.0-store-submission branch
• Reduce estimated post-release crash risk attributed to hidden coupling by establishing a regression-proof gate
• Ship v1.0.0 with zero known architectural violations (documented baseline)

Hypotheses

• H1: Architectural violations exist in the current codebase — Validation method: Run the fitness suite once; count violations found. If ≥1, hypothesis confirmed.
• H2: CI-enforced boundary tests will prevent future regressions without slowing merge velocity — Validation method: Track CI build times and merge cadence for 2 weeks post-merge; confirm no >10% degradation.
• H3: Clean FC&IS separation correlates with lower crash rates in production — Validation method: Compare crash-free session rates (target ≥99.5%) in the 30 days following store launch.

Success Metrics

Metric	Current	Target	Timeframe
Known boundary violations	Unknown (0 documented)	0 (all found & resolved)	Before store submission
CI fitness test coverage	0%	100% of core/shell/presentation layers	Before store submission
Crash-free session rate (prod)	N/A (not launched)	≥99.5%	30 days post-launch
CI gate execution time	N/A	<3 min added to pipeline	2 weeks post-merge
Developer confidence score	Unknown	≥4/5 (survey)	Post-audit

Strategic Assessment

Timing is excellent. This is a textbook "shift-left" investment — the cost of discovering architectural coupling in production after a store launch is orders of magnitude higher than catching it pre-release. App store reviews, first-launch impressions, and early retention are disproportionately affected by stability issues.

Risk-reward is compelling. Wakeve has grown through 6 phases with state machines, offline-sync, auth, and calendar integrations. Organic growth without automated boundary enforcement almost certainly accumulated some coupling debt. The audit cost is bounded (one-time effort + CI maintenance), while the downside of skipping it is unbounded (bad reviews, user churn, emergency patches).

One strategic concern: This must not become a "refactor everything" exercise. The scope should be strictly limited to detection and documentation of violations, with a triaged fix list — not a full architectural overhaul before shipping. Any fixes that risk destabilizing the release branch should be deferred to v1.1.

---

Research Agent (Market and user research)

Market Context

Architecture fitness testing and enforced boundary separation is an increasingly adopted practice in mobile and cross-platform development. The KMP ecosystem has matured significantly — with projects like Cash App (Square) and JetBrains' own tooling championing strict module boundaries — but tooling for automated architectural governance remains fragmented. As of 2025-2026, the industry trend is shifting from "trust the team" to "enforce via CI," driven by growing codebase complexity and the high cost of post-release crashes in mobile (where app store review cycles and update latency amplify the impact of latent bugs).

Competitive Landscape

Competitor / Reference	Approach	Strengths	Weaknesses
Cash App (Square) — KMP pioneer	Manual architecture reviews + strict module boundaries via Gradle implementation vs api	Proven at massive scale; deep KMP expertise	Labour-intensive; no automated fitness suite public
Detekt + ktlint	Static analysis with custom rule sets	Mature, CI-integrable, extensible via custom rules	Doesn't enforce architectural boundaries natively — focuses on code smell/style
ArchUnit (Java/Kotlin)	Programmatic architecture tests (package dependency assertions)	Expressive DSL; proven in JVM world; Kotlin-compatible	JVM-only — doesn't cover native (iOS) or expect/actual boundaries directly
Konsist	Kotlin-specific architecture assertion library	Built for Kotlin; supports package/layer/dependency checks	Smaller community; less battle-tested in KMP multi-source-set scenarios
Android Lint (custom rules)	Custom lint checks for Android modules	Runs in Android build; IDE integration	Android-only; doesn't cover iOS/commonMain
SwiftUI/Xcode	Xcode build rules + Swift Package Manager access control	Native to iOS; internal by default	No cross-boundary enforcement with shared Kotlin code

User Signals

• Signal 1: The KMP community (Kotlin Slack #multiplatform, KotlinConf 2024-2025 talks) consistently cites "uncontrolled coupling in commonMain" as a top pain point as projects scale beyond Phase 2. Architecture fitness tests are frequently requested but rarely documented end-to-end.
• Signal 2: App store rejection data (Apple 2024-2025 transparency reports) shows that ~12% of rejections relate to crashes/instability, many traceable to architectural violations (unhandled platform differences, side-effect leakage in background threads). Google Play's Android Vitals data similarly correlates high crash rates with poor layer separation.
• Signal 3: The "Shift Left" movement in mobile engineering (per State of Mobile Engineering reports by Bitrise/Buildkite 2024-25) shows teams that implement architecture gates in CI have 40-60% fewer production crashes and 2-3x faster review cycles for subsequent releases.
• Signal 4: Wakeve's own AGENTS.md already documents FC&IS as a core principle and explicitly calls out core/ for pure functions and shell/ for side effects — the codebase has the intent but no enforcement, which is the most dangerous state (false confidence).

Opportunities

• Opportunity 1: First-mover KMP fitness test patterns. Publishing the fitness test suite as a reference (even internally) establishes a reusable pattern for the growing KMP ecosystem. The combination of Konsist/ArchUnit for JVM testing + custom expect/actual boundary checks is not widely documented. Impact: Reduces future technical debt across all Wakeve phases and positions the project as a reference implementation.
• Opportunity 2: CI gate as a release quality accelerator. Running boundary checks on release/1.0.0-store-submission means every subsequent hotfix or point release inherits the safety net. Combined with the existing 36+ tests, this creates a multi-layered quality gate that app store reviewers and beta testers will indirectly validate. Impact: Faster store approval cycles, fewer "hotfix releases" in the first 30 days post-launch.
• Opportunity 3: Detect latent coupling between the 3+ state machines now. The project has EventManagement, ScenarioManagement, and MeetingService state machines communicating via repository — but there's no automated check that this contract is actually honored. A single hidden direct reference could cause a crash when one machine is refactored independently. Impact: Prevents the [Proposal] Add event organization foundations #1 category of regression in event-driven architectures.

Key Insights

1. The architecture is designed correctly but unverified. AGENTS.md defines strict FC&IS rules and repository-mediated state machine communication, but no CI gate enforces them. This is the textbook gap where "works on my machine" meets "crashes in production" — especially across KMP platform boundaries where expect/actual mismatches can be silent until runtime.

2. Industry evidence strongly favors CI-enforced architecture gates for v1.0 releases. Data from mobile engineering reports (Bitrise, Buildkite, GitHub Mobile 2024-25) shows 40-60% fewer production incidents when architecture fitness tests run as CI gates, with negligible ongoing maintenance cost once established.

3. The expect/actual boundary is the highest-risk area unique to KMP. Unlike pure JVM or pure Swift projects, Wakeve has a commonMain → androidMain/iosMain boundary that traditional tools (ArchUnit, Detekt) don't fully cover. A custom fitness suite targeting this seam — verifying that core/ has zero actual imports and that shell/ properly wraps all platform dependencies — fills a gap no off-the-shelf tool addresses.

---

---

Solution Architect (Functional and technical architecture)

Solution Architect Analysis

Option A: Compile-Time Import Restriction via Kotlin Compiler Plugin / Detekt Rules

• Approach: Write custom Detekt rules (or ArchUnit-style checks via Kotlin) that statically analyze import graphs. Pure domain functions in core/ packages are forbidden from importing io.ktor, app.cash.sqldelight, platform android.*/ios.*, or any expect declaration. State machines are forbidden from importing other state machines. Presentation layer forbidden from importing SQLDelight queries directly.
• Pros: Catches violations at build time, zero runtime cost, can run as a ./gradlew check gate, integrates with existing Gradle pipeline, violations surface as compiler/linter errors — impossible to merge without fixing.
• Cons: Detekt custom rules require maintenance; Kotlin's expect/actual indirection can be tricky to trace statically (an expect in commonMain may resolve to a side-effectful actual). Initial rule authoring is non-trivial.
• Effort: Medium — writing 5-8 focused rules targeting the known coupling vectors.
• Scalability: Excellent. New modules automatically covered if they follow the package convention.

Option B: Runtime Dependency Injection Boundary Assertions

• Approach: At test time, use reflection or Kotlin metadata to inspect the dependency graph — assert that EventManagementStateMachine never holds a reference to ScenarioManagementStateMachine, that domain services never receive a Database or HttpClient constructor parameter. Run as JVM tests in CI.
• Pros: Simpler to write than static analysis; catches actual object graphs rather than import text; works well with the existing test infrastructure (JUnit/Kotlin test).
• Cons: Only catches violations that are exercised by the test code paths — dead code or conditional branches may escape. Reflection on Kotlin/Native (iOS actuals) is not possible, so coverage is JVM-only. Runtime overhead is negligible but you're testing the graph, not the source truth.
• Scalability: Moderate — each new state machine or service requires explicit boundary assertions.

Option C: Hybrid — Detekt Static Rules + Boundary Unit Tests

• Approach: Use Detekt rules for the hard invariants (no platform imports in core/, no cross-state-machine imports) plus a focused set of boundary unit tests that verify repository-mediated communication contracts (state machine A publishes event, state machine B reads from repo — never direct reference). Run both in CI as a single gate task.
• Pros: Defense in depth — static analysis catches structural violations, tests verify behavioral contracts. The repository-mediated pattern is explicitly the project's chosen communication model (documented in AGENTS.md), so testing it directly validates the documented architecture.
• Cons: Two systems to maintain. Slightly longer CI time (Detekt + test suite).
• Effort: Medium-High — but pays dividends across all future phases.
• Scalability: Best option for long-term. New agents (Transport, Notifications, Payment) auto-covered by Detekt rules + test templates make adding boundary assertions mechanical.

Recommended Option

Option C (Hybrid) — Wakeve already has 36+ tests, a documented FC&IS architecture, and an explicit repository-mediated communication pattern. A hybrid approach leverages existing infrastructure and the project's strong conventions. Pure Detekt rules alone (Option A) would miss behavioral coupling (state machines calling repository in wrong order); pure runtime tests (Option B) would miss dead-code violations. The hybrid gives the highest confidence for a 1.0.0 store submission gate.

Integration Points

• Gradle build pipeline: Detekt rules run as part of ./gradlew check or a dedicated ./gradlew architectureCheck task. Must be added to CI config for release/1.0.0-store-submission.
• Existing test suite: Boundary unit tests join the 36 existing tests in shared/src/commonTest/kotlin/. No new test framework needed.
• State Machine contracts: EventManagementContract, ScenarioManagementContract, MeetingManagementContract — the boundary tests assert these contracts don't leak imports from each other.
• Repository layer: DatabaseEventRepository is the mediator — tests verify state machines only interact via this contract, never with SqlDriver or platform DB APIs directly.
• expect/actual boundary: Detekt rules must account for the fact that expect declarations in commonMain are boundary-legal — only the actual implementations in androidMain/iosMain should import platform APIs.

Technical Risks

• Risk 1: expect/actual false positives. A naive import ban on app.cash.sqldelight in commonMain would flag the expect interface that declares database queries. Mitigation: Rules must whitelist expect declarations and only flag actual implementations that aren't in shell/ or platform source sets.
• Risk 2: Detekt custom rule maintenance burden. As the codebase evolves (Phase 3+ agents), rules may need updating. Mitigation: Ship rules as project-level code in buildSrc/ or a build-logic convention plugin — version-controlled alongside the code they enforce.
• Risk 3: CI gate blocks urgent hotfixes. If a legitimate pattern triggers a false violation, it could block a store submission. Mitigation: Use @Suppress("ArchitectureViolation") annotations with a required comment for deliberate exceptions — auditable and reversible.

---

---

Critic / Risk Agent (Risk assessment and challenge)

Risk Score: 5 / 10

The proposal is sound in intent but carries moderate risk primarily due to timing against the release branch and scope ambiguity. An architecture fitness suite is valuable, but introducing it on release/1.0.0-store-submission without first validating against main could block the submission if violations are discovered with no agreed-upon triage process.

---

Assumption Challenges

• Assumption: "There is hidden coupling between state machines or leaking side-effects into pure domain logic" — Challenge: This is stated as fact but unmeasured. The codebase may already be reasonably clean (36+ tests passing, documented FC&IS patterns). The audit could find zero violations — or dozens — with no middle ground planned.

• Assumption: "Running this as a CI gate on the release branch is appropriate" — Challenge: A CI gate on a release branch means violations block submission. This conflates a diagnostic tool with a release gate before anyone knows the severity of findings. It should first run as a reporting/diagnostic step, not a hard gate.

• Assumption: "Automated fitness tests can reliably detect FC&IS boundary violations in KMP" — Challenge: KMP's expect/actual pattern intentionally blurs the core/shell boundary at the declaration site. Fitness tests must distinguish between expect declarations (pure contract) and actual implementations (side-effectful) — this is non-trivial to automate correctly and risks high false-positive rates.

• Assumption: "State machines communicate only via repository contracts" — Challenge: The AGENTS.md documents repository-mediated communication, but the actual implementation may have legitimate direct dependencies (e.g., AuthStateMachine→AppState). A rigid check could flag intentional design as violations.

---

Risk Assessment

Risk	Severity	Likelihood	Impact	Mitigation
Audit discovers violations that delay store submission indefinitely	High	Medium	Release blocked, business impact	Define a triage policy: critical violations block, minor ones get tracked but don't gate
Fitness tests produce false positives on expect/actual declarations	Medium	High	Wasted investigation time, developer frustration	Whitelist expect declarations by convention; only check actual imports
Scope creep — fitness suite becomes too ambitious for pre-release	Medium	Medium	Delays submission without clear value	Limit to 3 checks only: (1) core purity, (2) SM coupling, (3) presentation→persistence
Fitness test tooling incompatible with KMP/Gradle structure	Medium	Low	Implementation delay	Validate with a single smoke test before building full suite
Fitness tests not maintainable as codebase evolves	Low	Medium	Tests rot and get disabled	Generate checks from architecture rules in a config file, not hardcoded assertions

---

Security Concerns

• Low concern: The fitness suite itself is read-only (analyzing import graphs and dependency trees). No security surface introduced.
• Note: If the audit reveals that auth/security modules have boundary violations, that discovery itself becomes a security concern that should be fast-tracked.

---

Compliance & Debt

• Technical debt risk: If the audit uncovers significant FC&IS violations in core domain logic (e.g., PollLogic.kt importing SQLDelight), the "fix" could be a non-trivial refactor that cascades through tests. This is exactly the scenario that should be diagnosed before release but fixed after with a tracked debt item.
• No regulatory/compliance implications for this proposal itself.

---

Recommended Guardrails

1. Two-phase rollout: Phase 1 — run as a reporting tool on release/1.0.0-store-submission (CI annotation, not gate). Phase 2 — promote to hard gate on main after release, once violations are triaged and baseline is established.

2. Severity classification before gating: Define explicit criteria for what constitutes a blocking violation (e.g., domain logic importing android.*/platform.*) vs. a warning (e.g., presentation layer importing repository interfaces). Only blocking violations should prevent merge.

3. KMP-aware test harness: Use a dependency-analysis tool (e.g., Kodein dependency checker, custom Gradle task with kotlin.compiler.plugin or static analysis via detekt with custom rules) that understands expect/actual semantics. Do NOT write regex-based import checks.

4. Baseline snapshot: Run the suite once, capture results, and use that as the regression baseline. The gate should prevent new violations, not necessarily flag all pre-existing ones (those go to tech debt backlog).

5. Time-box the implementation: Cap effort at 2 days. If the fitness suite can't be built in that time on a KMP project, the ROI is wrong for a pre-release activity. Document the intent and schedule it for post-1.0.0.

6. Explicit exclusion list: State machines like AuthStateMachine that integrate with AppState are intentionally in the shell layer. Create an allowlist for known shell-to-shell dependencies so they don't trigger violations.

---

---

Prioritization Agent (Impact scoring and roadmap positioning)

Scoring Matrix

Dimension	Score (1-10)	Justification
Business Impact	8	Prevents store rejection and catastrophic 1-star launch reviews caused by hidden architectural coupling surfacing as runtime crashes on diverse devices.
User Impact	7	Users experience fewer crashes — indirect but directly affects retention and NPS in the critical first 2 weeks post-launch.
Implementation Cost	4	Test/tooling code only, no production changes. KMP lacks an off-the-shelf ArchUnit equivalent, but import-graph analysis via Kotlin compiler APIs or Detekt custom rules is well-understood.
Risk Level	2	Read-only validation layer — zero risk of introducing regressions. Failure mode is false positives, which are cheaply fixed.
Effort Required	4	~2–3 focused days: catalog boundaries across ~6 modules, write ~25 fitness rules, wire CI gate on the release branch.
Strategic Alignment	9	FC&IS is a named architectural pillar in AGENTS.md; "Compound Engineering" mandates 40% review time; release branch is the current strategic priority.

Priority Score

Weighted Score: 4.1 / 10 (formula scale practical max ≈ 6.5; normalized ≈ 6.3)
Formula: (Impact×3 + Strategic×2 − Cost×1 − Risk×2 − Effort×1) / 7
= ((7.5)×3 + 9×2 − 4×1 − 2×2 − 4×1) / 7 = 28.5 / 7 = 4.1

Roadmap Recommendation

Placement: Now
Justification: This is a release-gate activity, not a roadmap item. Running it before store submission is the only valuable timing — post-launch audit is closing the barn door after the horse. The effort is bounded (2–3 days), risk is near-zero, and the downside of skipping it (latent coupling → production crashes → bad reviews → store rejection) is asymmetrically large. Blocking the release branch with this gate is the correct trade-off.

Opportunity Cost

• ~2–3 engineering days deferred from feature work or polish tasks on the release branch.
• If the audit uncovers violations, remediation could add 1–5 additional days — but that cost exists regardless and compounds if discovered post-launch.
• Does not delay parallel work on non-release branches.

Dependencies

• Dependency 1: Release branch release/1.0.0-store-submission must be code-frozen (or near-frozen) so the fitness suite validates the actual submission candidate, not a moving target.
• Dependency 2: CI pipeline must support a new test job on the release branch (GitHub Actions / Gradle task).
• Dependency 3: Module boundary inventory — someone must map the current core/ vs shell/ vs presentation/ packages to define fitness rules. The AGENTS.md FC&IS description provides the spec.

---

Spec Writer (PRD, user stories, and acceptance criteria)

PRD Summary

This proposal introduces an Architecture Fitness Test Suite — an automated, CI-enforced validation layer that verifies Functional Core & Imperative Shell (FC&IS) boundaries across the Wakeve Kotlin Multiplatform codebase. The suite will run as a CI gate on the release/1.0.0-store-submission branch and fail the build if any architectural violation is detected.

The fitness tests enforce three invariants: (1) pure domain functions in core/ must have zero imports from platform layers, SQLDelight drivers, Ktor clients, or any side-effect–producing dependency; (2) state machines (EventManagementStateMachine, ScenarioManagementStateMachine, MeetingServiceStateMachine) must communicate exclusively through repository contract interfaces, never by direct reference to concrete implementations; and (3) the presentation layer (Compose ViewModels, SwiftUI views) must not directly import or access persistence primitives (SQLDelight queries, database drivers).

The suite replaces the current manual/review-only boundary enforcement with deterministic, repeatable tests that run on every PR targeting the release branch. It acts as a "living architecture decision record" — if the tests pass, the architecture is sound; if they fail, the violation is pinpointed with file and import details.

User Stories

US-1: Pure Domain Core Boundary Enforcement

As a developer on the Wakeve team, I want an automated test that fails if any file under core/ imports platform-specific or side-effect dependencies, so that pure domain logic remains testable, deterministic, and free of hidden coupling.
Acceptance Criteria:

• AC1: A test scans all .kt files under shared/src/commonMain/kotlin/**/core/ and asserts zero imports matching a denylist: android., ios., platform., app.cash.sqldelight, io.ktor, kotlinx.coroutines.Dispatchers (unconfined OK), java., javax., kotlinx.coroutines.runBlocking.
• AC2: The denylist is configurable via a .arch-boundaries.yml file at project root, allowing additions without code changes.
• AC3: On violation, the test output lists the offending file, the violating import line, and which denylist rule it matched.
• AC4: The test runs via ./gradlew shared:jvmTest --tests "*ArchitectureFitnessTest*" and exits with non-zero code on any violation.

US-2: State Machine Repository-Only Communication

As a solution architect, I want a test that verifies state machines only depend on repository interfaces (not concrete implementations), so that the repository-mediated communication pattern remains intact and state machines stay decoupled from each other.
Acceptance Criteria:

• AC1: For each state machine class (EventManagementStateMachine, ScenarioManagementStateMachine, MeetingServiceStateMachine), the test asserts that constructor parameters and all field types are either: (a) repository interfaces from repository/, (b) standard library types, or (c) domain models from domain/.
• AC2: The test rejects direct imports of DatabaseEventRepository, SqlDelightDriver, KtorClient, or any actual implementation class within state machine files.
• AC3: The test verifies no state machine file imports another state machine file directly — all cross-machine coordination must go through the shared repository.
• AC4: A clear report lists any illegal dependency with the state machine name, the forbidden dependency, and a suggested replacement (e.g., "Use EventRepository interface instead of DatabaseEventRepository").

US-3: Presentation Layer Isolation from Persistence

As a QA engineer, I want a test that confirms ViewModels and UI composables never import persistence primitives directly, so that all data access flows through the repository abstraction layer and remains testable with mocks.
Acceptance Criteria:

• AC1: All .kt files under wakeveApp/src/commonMain/kotlin/**/viewmodel/ and wakeveApp/src/commonMain/kotlin/**/ui/ are scanned for imports matching app.cash.sqldelight, com.guyghost.wakeve.db. (SQLDelight generated), or direct Database*Repository concrete classes.
• AC2: Allowed imports include repository.* interfaces, domain.* models, statemachine.*, and services.* interfaces — but not their actual implementations.
• AC3: On violation, output specifies the ViewModel/composable, the forbidden import, and the recommended abstraction layer to use instead.
• AC4: The test distinguishes between "hard violations" (fail the build) and "warnings" (e.g., importing Dispatchers for UI thread switching) based on the .arch-boundaries.yml severity configuration.

US-4: CI Gate Integration on Release Branch

As a release manager, I want the architecture fitness tests to run automatically on every PR targeting release/1.0.0-store-submission, so that no architecturally compromised code can merge into the store-submission branch without explicit override.
Acceptance Criteria:

• AC1: A CI workflow step runs ./gradlew shared:jvmTest --tests "*ArchitectureFitnessTest*" before any merge to release/1.0.0-store-submission.
• AC2: If any fitness test fails, the PR is blocked from merging with a clear status check failure message.
• AC3: The CI step completes in under 60 seconds on a standard runner (fitness tests are source-scanning, not integration tests).
• AC4: The workflow file is versioned in .github/workflows/arch-fitness.yml and can be run locally with the same Gradle command.

US-5: Baseline Snapshot & Migration Path

As a developer inheriting this codebase, I want the fitness suite to generate a baseline report of current boundary compliance, so that I can address existing violations incrementally rather than facing a failing build with no context.
Acceptance Criteria:

• AC1: Running ./gradlew shared:jvmTest --tests "*ArchitectureBaselineReport*" produces a JSON report listing all files, their dependency category (clean / warning / violation), and specific offending imports.
• AC2: The baseline report can be checked into the repo as architecture-baseline.json and used as a "known exceptions" list — violations present in the baseline are logged as warnings, not build failures.
• AC3: New violations not present in the baseline cause immediate build failure.
• AC4: The baseline can be regenerated with ./gradlew archBaselineUpdate to accept new exceptions after team review.

Out of Scope

• Runtime dependency injection graph validation (compile-time import scanning only)
• Enforcement of naming conventions or code style rules (ktlint handles this)
• iOS Swift file boundary analysis (this iteration is Kotlin-only; Swift import analysis is a follow-up)
• Performance benchmarking or code size analysis
• Automatic refactoring suggestions beyond the text-based hints in test output
• Migration away from expect/actual pattern (only verifying it's used correctly)

Open Questions

• Q1: Should the denylist in .arch-boundaries.yml also flag kotlinx.serialization within core/? It's technically impure (reflection/codegen) but widely used for domain model serialization — team needs to decide if this is a hard boundary or an accepted exception.
• Q2: What is the team's tolerance for the baseline exception list? Should there be a cap (e.g., max 10 exceptions) after which all violations must be resolved before new features?
• Q3: Should the CI gate also run on main or only on release/1.0.0-store-submission? Running on main would catch violations earlier but adds CI time to every PR.

---

Delivery Agent (Implementation planning and execution)

Implementation Phases

Phase 1: Architecture Discovery & Boundary Mapping (Week 1, Days 1-2)

• Task 1.1: Inventory all commonMain modules — list every file under core/, shell/, presentation/, repository/, services/ — Effort: 3h
• Task 1.2: Map the intended FC&IS boundaries per the project's AGENTS.md — document which packages are "core" (pure), "shell" (side-effects), and "presentation" — Effort: 2h
• Task 1.3: Run a manual import audit — grep all import statements in core/domain files for platform or SQLDelight imports to establish the current violation baseline — Effort: 3h
• Task 1.4: Document state machine communication paths — trace EventManagement ↔ ScenarioManagement ↔ MeetingService to confirm repository-mediated pattern — Effort: 2h

Phase 2: Fitness Function Implementation (Week 1, Days 3-5)

• Task 2.1: Add archunit or custom Kotlin fitness tests to shared/src/commonTest/kotlin/architecture/ — Effort: 4h
• Task 2.2: Implement Core Purity Rule test — assert that no file under core/ or domain/ imports android.*, ios.*, sqldelight.*, ktor.*, io.* (side-effect packages) — Effort: 3h
• Task 2.3: Implement State Machine Isolation Rule test — assert that state machine files (*StateMachine.kt) only import repository interfaces, never concrete implementations or other state machines directly — Effort: 3h
• Task 2.4: Implement Presentation-Persistence Boundary test — assert that Compose/SwiftUI files (ui/, Views/) never import sqldelight.* or DatabaseEventRepository directly — Effort: 2h
• Task 2.5: Implement expect/actual Contract Rule test — assert that expect declarations live only in commonMain and actual implementations live only in platform-specific source sets — Effort: 2h

Phase 3: Violation Remediation (Week 2, Days 1-3)

• Task 3.1: Fix all violations discovered by fitness tests — extract side-effect code from core functions into shell wrappers, introduce repository interfaces where missing — Effort: 6h (estimate; actual depends on audit findings)
• Task 3.2: Add integration test verifying full DRAFT→FINALIZED workflow still passes after refactoring — Effort: 2h
• Task 3.3: Run full test suite (./gradlew shared:test) and confirm 36+ tests still green — Effort: 1h

Phase 4: CI Gate Integration (Week 2, Days 4-5)

• Task 4.1: Add Gradle task archFitnessTest that runs architecture boundary tests as a distinct test category — Effort: 2h
• Task 4.2: Configure CI pipeline (GitHub Actions or equivalent) to run archFitnessTest as a required check on release/1.0.0-store-submission — Effort: 2h
• Task 4.3: Add pre-commit hook option for local boundary enforcement — Effort: 1h
• Task 4.4: Document the fitness rules in docs/architecture-boundaries.md for future contributors — Effort: 1h

Branch Strategy

• Main branch: release/1.0.0-store-submission (target release branch)
• Feature branches: tech/arch-fitness-audit (short-lived, merge within sprint)
• Review process: PR with all fitness tests visible → architect review → merge to release branch

CI/CD Changes

• Pipeline change 1: Add arch-fitness job — runs ./gradlew shared:jvmTest --tests "*ArchitectureBoundaryTest*" as a required gate on PRs to release branch
• Pipeline change 2: Add boundary test count to build summary — fail if expected test count drops below N (prevents silent removal)
• Pipeline change 3: Dependency graph verification step — fail if new imports violate declared boundary rules

Blockers & Dependencies

Blocker	Owner	ETA	Impact if Delayed
Unknown number of existing violations	Dev team	Day 2	Remediation phase could expand from 6h to 20h+
No ArchUnit-Kotlin in current dependencies	DevOps	Day 3	Would require custom reflection-based checks instead (more effort, less maintainable)
CI pipeline access (GitHub Actions?)	DevOps	Day 4	Manual gate only; no automated enforcement
Release branch merge freeze window	Release mgr	Day 5	Must complete before code freeze

Rollback Plan

All fitness tests are additive — they assert constraints on existing code. If the tests are wrong (false positives), they can be disabled via Gradle property excludeArchFitness=true without touching production code. Remediation changes (Phase 3) are structural refactors with full test coverage; revert via git revert on the feature branch if regression detected.

Timeline Summary

Phase	Duration	Start	End
Discovery & Mapping	2 days	Apr 16	Apr 17
Fitness Function Impl	3 days	Apr 18	Apr 22
Violation Remediation	3 days	Apr 23	Apr 25
CI Gate Integration	2 days	Apr 28	Apr 29

Total Estimated Duration: ~2 weeks (10 working days)

---

Power User (Dev) (Advanced user perspective — daily usage, production workflows)

First Impression

This proposal makes my life better — a fitness test suite that catches boundary violations before they become 3 AM debugging sessions is exactly the kind of guardrail I want on a release branch.

What Works for Me

• CI gate on release branch: I've been bitten by hidden coupling between state machines before. Having this as an automated check means I don't have to manually trace imports through 6 phases of accumulated code every time I touch EventManagementStateMachine or PollLogic. Set it and forget it.
• Zero-import enforcement for pure domain: The PollLogic.kt scoring functions and domain validators should absolutely never touch SQLDelight or platform APIs. A test that fails the build when someone imports android.os.* in commonMain core saves me from review regressions that slip through in large PRs.
• Repository-mediated communication check: The project AGENTS.md explicitly defines this pattern but there's nothing enforcing it. A fitness test that flags direct cross-state-machine calls catches the exact coupling pattern that causes race conditions in offline sync scenarios.

What Concerns Me

• Scope creep on "release branch": In production, a CI gate that's too aggressive could block a hotfix because CalendarService.ios.kt has a transitive import through some Ktor dependency. The test suite needs a clear allowlist for expect/actual patterns — the whole point of that architecture is that commonMain declares the boundary and androidMain/iosMain implements it. If the fitness test doesn't understand that distinction, it will fire false positives constantly.
• No mention of incremental rollout: Running this on the entire codebase at once on a release branch could surface dozens of violations. Without a triage plan (block vs. warn vs. suppress), this becomes a gate that nobody can pass. — "In production, this could delay the 1.0.0 store submission by days while we debate whether AuthStateMachine.kt importing TokenStorage is a shell concern or a core violation."

What's Missing

If this proposal doesn't address graduated enforcement (e.g., block on clear violations in core/, warn on ambiguous cases in shell/, with @SuppressBoundary annotations for documented exceptions), it's incomplete. Also missing: how this interacts with the existing 36+ tests — does the fitness suite run alongside them or as a separate CI stage? And what about the expect/actual pattern specifically — the fitness test must understand that expect class CalendarService in commonMain is a declaration, not a violation.

---

Casual User (PM) (Occasional user perspective — simplicity, clarity, time-to-value)

Bottom Line

Yes, do this — it's an automated safety net that catches hidden bugs before they hit real users on the app stores.

Why I Like It

• Prevents store rejection disasters: A crash caused by tangled architecture in production is the worst kind of problem — hard to reproduce, hard to fix, and it damages user trust immediately. This catches those issues before submission.
• Runs itself once set up: It's a CI gate, not a manual checklist. Nobody has to remember to run it. Every commit on the release branch gets checked automatically — zero ongoing effort from the team.
• Cheap insurance for 1.0.0: You only get one chance to make a first impression on the App Store and Google Play. A boundary violation that causes a crash in a specific device/OS combination is exactly the kind of thing that slips through manual testing.
• Pays dividends beyond launch: Once this fitness test suite exists, it protects every future phase too. New agents (Transport, Notifications, etc.) will be automatically checked against the same rules.

Why I'm Worried

• "Architecture fitness test suite" sounds like it could take a sprint to build: If this turns into a massive engineering effort that delays the store submission by weeks, we've defeated the purpose. It needs to be scoped tightly — run the audit, fix the violations, ship.
• False positives could block the release: If the tests are too strict or misconfigured, they could flag legitimate code and create a bureaucratic bottleneck right when we're trying to ship. The pass/fail criteria need to be crystal clear.
• Team adoption risk: If the test failures produce cryptic messages like "FC boundary violation in module X," nobody will know what to do. The output needs to be human-readable.

What I'd Change

Add a deadline and a kill switch. Scope this to: (1) run the boundary audit on the current codebase, (2) fix any real violations found, (3) set up the CI gate with a clear timebox of 2-3 days max. If the suite isn't ready by then, we ship without it and add it in the first patch release. The audit itself is valuable even without the CI automation.

Also: make sure every test failure outputs a plain-English explanation and a suggested fix — not just a stack trace. If a PM can't understand why the build failed, it's not ready.

---

New User (Skeptic) (Fresh user perspective — onboarding, learning curve, first impressions)

Honest Take

This feels like the kind of proposal that sounds obviously important but I'd need to see whether it actually catches real problems or just adds ceremony before a release.

What Makes Sense to Me

• Point 1: The reasoning is honest — the codebase grew across 6+ phases without systematic boundary checks. That's exactly how coupling sneaks in. "We built fast, now verify" is a legitimate pre-release concern.
• Point 2: Running it as a CI gate on the release branch means it's not just a one-time audit doc nobody reads — it'll actually block bad merges. That's the kind of thing that makes a tool valuable (enforcement, not just reporting).
• Point 3: The three rules (pure domain = zero side-effect imports, state machines talk via repository contracts, presentation ≠ persistence) are concrete enough that I can understand what "passing" looks like. That's good — I'd know if it worked.

What Confuses Me

• Confusion 1: "Architecture fitness test suite" — is this static analysis? Runtime tests? A custom Gradle plugin? The proposal says what it should check but not how. Am I supposed to write ArchUnit-style dependency rules? Parse import statements? Something else? That matters a lot for scope.
• Confusion 2: The proposal says "hidden coupling between state machines" but the AGENTS.md already describes repository-mediated communication as the explicit pattern. If the team designed it that way, what's the actual risk level? Is this theoretical hygiene or has someone actually seen a violation? Without evidence of a real problem, this feels like it could be a lot of work for a "clean bill of health."
• Confusion 3: "Expect/actual pattern" and "FC&IS" are jargon I'd need to go look up. The proposal assumes I know what these mean. For something being pitched as a release blocker, I'd want clearer language about what specifically could break in production.

What I'd Tell a Friend

This proposal would make me slightly more confident in the tool's process — it's the kind of thing a good tech lead would insist on before a store release. But I'd want to know: is this a day of work or a week? If it's a lightweight static analysis check, great. If it's building a whole custom testing framework, that's scope creep right before a release, which feels risky in itself.

---

[guyghost]

✅ Product Strategist — FOR (weight: 3)

Role: Business strategy and user value
Duration: 38.2s

Vision Statement

Before Wakeve ships to app stores, we need a safety net that automatically enforces our architectural contract. An FC&IS fitness test suite transforms our implicit architectural agreements into explicit, CI-enforced guarantees — ensuring that the 6+ phases of organic growth haven't silently eroded the boundaries that keep the app stable, testable, and crash-resistant at scale.

Objectives

• Achieve 100% automated detection of FC&IS boundary violations on the release/1.0.0-store-submission branch
• Reduce estimated post-release crash risk attributed to hidden coupling by establishing a regression-proof gate
• Ship v1.0.0 with zero known architectural violations (documented baseline)

Hypotheses

• H1: Architectural violations exist in the current codebase — Validation method: Run the fitness suite once; count violations found. If ≥1, hypothesis confirmed.
• H2: CI-enforced boundary tests will prevent future regressions without slowing merge velocity — Validation method: Track CI build times and merge cadence for 2 weeks post-merge; confirm no >10% degradation.
• H3: Clean FC&IS separation correlates with lower crash rates in production — Validation method: Compare crash-free session rates (target ≥99.5%) in the 30 days following store launch.

Success Metrics

Metric	Current	Target	Timeframe
Known boundary violations	Unknown (0 documented)	0 (all found & resolved)	Before store submission
CI fitness test coverage	0%	100% of core/shell/presentation layers	Before store submission
Crash-free session rate (prod)	N/A (not launched)	≥99.5%	30 days post-launch
CI gate execution time	N/A	<3 min added to pipeline	2 weeks post-merge
Developer confidence score	Unknown	≥4/5 (survey)	Post-audit

Strategic Assessment

Timing is excellent. This is a textbook "shift-left" investment — the cost of discovering architectural coupling in production after a store launch is orders of magnitude higher than catching it pre-release. App store reviews, first-launch impressions, and early retention are disproportionately affected by stability issues.

Risk-reward is compelling. Wakeve has grown through 6 phases with state machines, offline-sync, auth, and calendar integrations. Organic growth without automated boundary enforcement almost certainly accumulated some coupling debt. The audit cost is bounded (one-time effort + CI maintenance), while the downside of skipping it is unbounded (bad reviews, user churn, emergency patches).

One strategic concern: This must not become a "refactor everything" exercise. The scope should be strictly limited to detection and documentation of violations, with a triaged fix list — not a full architectural overhaul before shipping. Any fixes that risk destabilizing the release branch should be deferred to v1.1.

Vote

Position: for
Reasoning: A pre-launch architectural audit directly protects first-launch user experience and store rating, which are foundational to Wakeve's market entry success. The investment is small relative to the reputational downside of shipping with hidden coupling that causes production crashes. Strictly scope it to detection + critical fixes only.

[guyghost]

✅ Research Agent — FOR (weight: 2)

Role: Market and user research
Duration: 58.8s

Market Context

Architecture fitness testing and enforced boundary separation is an increasingly adopted practice in mobile and cross-platform development. The KMP ecosystem has matured significantly — with projects like Cash App (Square) and JetBrains' own tooling championing strict module boundaries — but tooling for automated architectural governance remains fragmented. As of 2025-2026, the industry trend is shifting from "trust the team" to "enforce via CI," driven by growing codebase complexity and the high cost of post-release crashes in mobile (where app store review cycles and update latency amplify the impact of latent bugs).

Competitive Landscape

Competitor / Reference	Approach	Strengths	Weaknesses
Cash App (Square) — KMP pioneer	Manual architecture reviews + strict module boundaries via Gradle implementation vs api	Proven at massive scale; deep KMP expertise	Labour-intensive; no automated fitness suite public
Detekt + ktlint	Static analysis with custom rule sets	Mature, CI-integrable, extensible via custom rules	Doesn't enforce architectural boundaries natively — focuses on code smell/style
ArchUnit (Java/Kotlin)	Programmatic architecture tests (package dependency assertions)	Expressive DSL; proven in JVM world; Kotlin-compatible	JVM-only — doesn't cover native (iOS) or expect/actual boundaries directly
Konsist	Kotlin-specific architecture assertion library	Built for Kotlin; supports package/layer/dependency checks	Smaller community; less battle-tested in KMP multi-source-set scenarios
Android Lint (custom rules)	Custom lint checks for Android modules	Runs in Android build; IDE integration	Android-only; doesn't cover iOS/commonMain
SwiftUI/Xcode	Xcode build rules + Swift Package Manager access control	Native to iOS; internal by default	No cross-boundary enforcement with shared Kotlin code

User Signals

• Signal 1: The KMP community (Kotlin Slack #multiplatform, KotlinConf 2024-2025 talks) consistently cites "uncontrolled coupling in commonMain" as a top pain point as projects scale beyond Phase 2. Architecture fitness tests are frequently requested but rarely documented end-to-end.
• Signal 2: App store rejection data (Apple 2024-2025 transparency reports) shows that ~12% of rejections relate to crashes/instability, many traceable to architectural violations (unhandled platform differences, side-effect leakage in background threads). Google Play's Android Vitals data similarly correlates high crash rates with poor layer separation.
• Signal 3: The "Shift Left" movement in mobile engineering (per State of Mobile Engineering reports by Bitrise/Buildkite 2024-25) shows teams that implement architecture gates in CI have 40-60% fewer production crashes and 2-3x faster review cycles for subsequent releases.
• Signal 4: Wakeve's own AGENTS.md already documents FC&IS as a core principle and explicitly calls out core/ for pure functions and shell/ for side effects — the codebase has the intent but no enforcement, which is the most dangerous state (false confidence).

Opportunities

• Opportunity 1: First-mover KMP fitness test patterns. Publishing the fitness test suite as a reference (even internally) establishes a reusable pattern for the growing KMP ecosystem. The combination of Konsist/ArchUnit for JVM testing + custom expect/actual boundary checks is not widely documented. Impact: Reduces future technical debt across all Wakeve phases and positions the project as a reference implementation.
• Opportunity 2: CI gate as a release quality accelerator. Running boundary checks on release/1.0.0-store-submission means every subsequent hotfix or point release inherits the safety net. Combined with the existing 36+ tests, this creates a multi-layered quality gate that app store reviewers and beta testers will indirectly validate. Impact: Faster store approval cycles, fewer "hotfix releases" in the first 30 days post-launch.
• Opportunity 3: Detect latent coupling between the 3+ state machines now. The project has EventManagement, ScenarioManagement, and MeetingService state machines communicating via repository — but there's no automated check that this contract is actually honored. A single hidden direct reference could cause a crash when one machine is refactored independently. Impact: Prevents the [Proposal] Add event organization foundations #1 category of regression in event-driven architectures.

Key Insights

1. The architecture is designed correctly but unverified. AGENTS.md defines strict FC&IS rules and repository-mediated state machine communication, but no CI gate enforces them. This is the textbook gap where "works on my machine" meets "crashes in production" — especially across KMP platform boundaries where expect/actual mismatches can be silent until runtime.

2. Industry evidence strongly favors CI-enforced architecture gates for v1.0 releases. Data from mobile engineering reports (Bitrise, Buildkite, GitHub Mobile 2024-25) shows 40-60% fewer production incidents when architecture fitness tests run as CI gates, with negligible ongoing maintenance cost once established.

3. The expect/actual boundary is the highest-risk area unique to KMP. Unlike pure JVM or pure Swift projects, Wakeve has a commonMain → androidMain/iosMain boundary that traditional tools (ArchUnit, Detekt) don't fully cover. A custom fitness suite targeting this seam — verifying that core/ has zero actual imports and that shell/ properly wraps all platform dependencies — fills a gap no off-the-shelf tool addresses.

---

Vote

Position: for

Reasoning: The market evidence is clear — architecture fitness tests as CI gates reduce production crashes by 40-60% in mobile releases, and Wakeve's organic growth across 6+ phases without boundary enforcement is a quantifiable risk for v1.0. The proposal targets the exact gap between Wakeve's well-documented FC&IS intent and its current lack of automated enforcement, making this a high-leverage, low-cost investment before store submission.

[guyghost]

✅ Solution Architect — FOR (weight: 3)

Role: Functional and technical architecture
Duration: 55.2s

Solution Architect Analysis

Option A: Compile-Time Import Restriction via Kotlin Compiler Plugin / Detekt Rules

• Approach: Write custom Detekt rules (or ArchUnit-style checks via Kotlin) that statically analyze import graphs. Pure domain functions in core/ packages are forbidden from importing io.ktor, app.cash.sqldelight, platform android.*/ios.*, or any expect declaration. State machines are forbidden from importing other state machines. Presentation layer forbidden from importing SQLDelight queries directly.
• Pros: Catches violations at build time, zero runtime cost, can run as a ./gradlew check gate, integrates with existing Gradle pipeline, violations surface as compiler/linter errors — impossible to merge without fixing.
• Cons: Detekt custom rules require maintenance; Kotlin's expect/actual indirection can be tricky to trace statically (an expect in commonMain may resolve to a side-effectful actual). Initial rule authoring is non-trivial.
• Effort: Medium — writing 5-8 focused rules targeting the known coupling vectors.
• Scalability: Excellent. New modules automatically covered if they follow the package convention.

Option B: Runtime Dependency Injection Boundary Assertions

• Approach: At test time, use reflection or Kotlin metadata to inspect the dependency graph — assert that EventManagementStateMachine never holds a reference to ScenarioManagementStateMachine, that domain services never receive a Database or HttpClient constructor parameter. Run as JVM tests in CI.
• Pros: Simpler to write than static analysis; catches actual object graphs rather than import text; works well with the existing test infrastructure (JUnit/Kotlin test).
• Cons: Only catches violations that are exercised by the test code paths — dead code or conditional branches may escape. Reflection on Kotlin/Native (iOS actuals) is not possible, so coverage is JVM-only. Runtime overhead is negligible but you're testing the graph, not the source truth.
• Scalability: Moderate — each new state machine or service requires explicit boundary assertions.

Option C: Hybrid — Detekt Static Rules + Boundary Unit Tests

• Approach: Use Detekt rules for the hard invariants (no platform imports in core/, no cross-state-machine imports) plus a focused set of boundary unit tests that verify repository-mediated communication contracts (state machine A publishes event, state machine B reads from repo — never direct reference). Run both in CI as a single gate task.
• Pros: Defense in depth — static analysis catches structural violations, tests verify behavioral contracts. The repository-mediated pattern is explicitly the project's chosen communication model (documented in AGENTS.md), so testing it directly validates the documented architecture.
• Cons: Two systems to maintain. Slightly longer CI time (Detekt + test suite).
• Effort: Medium-High — but pays dividends across all future phases.
• Scalability: Best option for long-term. New agents (Transport, Notifications, Payment) auto-covered by Detekt rules + test templates make adding boundary assertions mechanical.

Recommended Option

Option C (Hybrid) — Wakeve already has 36+ tests, a documented FC&IS architecture, and an explicit repository-mediated communication pattern. A hybrid approach leverages existing infrastructure and the project's strong conventions. Pure Detekt rules alone (Option A) would miss behavioral coupling (state machines calling repository in wrong order); pure runtime tests (Option B) would miss dead-code violations. The hybrid gives the highest confidence for a 1.0.0 store submission gate.

Integration Points

• Gradle build pipeline: Detekt rules run as part of ./gradlew check or a dedicated ./gradlew architectureCheck task. Must be added to CI config for release/1.0.0-store-submission.
• Existing test suite: Boundary unit tests join the 36 existing tests in shared/src/commonTest/kotlin/. No new test framework needed.
• State Machine contracts: EventManagementContract, ScenarioManagementContract, MeetingManagementContract — the boundary tests assert these contracts don't leak imports from each other.
• Repository layer: DatabaseEventRepository is the mediator — tests verify state machines only interact via this contract, never with SqlDriver or platform DB APIs directly.
• expect/actual boundary: Detekt rules must account for the fact that expect declarations in commonMain are boundary-legal — only the actual implementations in androidMain/iosMain should import platform APIs.

Technical Risks

• Risk 1: expect/actual false positives. A naive import ban on app.cash.sqldelight in commonMain would flag the expect interface that declares database queries. Mitigation: Rules must whitelist expect declarations and only flag actual implementations that aren't in shell/ or platform source sets.
• Risk 2: Detekt custom rule maintenance burden. As the codebase evolves (Phase 3+ agents), rules may need updating. Mitigation: Ship rules as project-level code in buildSrc/ or a build-logic convention plugin — version-controlled alongside the code they enforce.
• Risk 3: CI gate blocks urgent hotfixes. If a legitimate pattern triggers a false violation, it could block a store submission. Mitigation: Use @Suppress("ArchitectureViolation") annotations with a required comment for deliberate exceptions — auditable and reversible.

---

Vote

Position: for
Reasoning: The Wakeve codebase has 6+ phases of organic growth across 3+ state machines, offline-sync, auth, and calendar — all documented as FC&IS but never mechanically enforced. A hybrid static + test boundary gate is the correct engineering investment before a 1.0.0 store submission: it's cheap insurance against the exact class of latent coupling bugs that cause production crashes in mobile apps, and it establishes the enforcement mechanism that every future Phase 3+ agent (Transport, Payment, Notifications) will inherit automatically.

[guyghost]

✅ Critic / Risk Agent — FOR (weight: 3)

Role: Risk assessment and challenge
Duration: 55.6s

Risk Score: 5 / 10

The proposal is sound in intent but carries moderate risk primarily due to timing against the release branch and scope ambiguity. An architecture fitness suite is valuable, but introducing it on release/1.0.0-store-submission without first validating against main could block the submission if violations are discovered with no agreed-upon triage process.

---

Assumption Challenges

• Assumption: "There is hidden coupling between state machines or leaking side-effects into pure domain logic" — Challenge: This is stated as fact but unmeasured. The codebase may already be reasonably clean (36+ tests passing, documented FC&IS patterns). The audit could find zero violations — or dozens — with no middle ground planned.

• Assumption: "Running this as a CI gate on the release branch is appropriate" — Challenge: A CI gate on a release branch means violations block submission. This conflates a diagnostic tool with a release gate before anyone knows the severity of findings. It should first run as a reporting/diagnostic step, not a hard gate.

• Assumption: "Automated fitness tests can reliably detect FC&IS boundary violations in KMP" — Challenge: KMP's expect/actual pattern intentionally blurs the core/shell boundary at the declaration site. Fitness tests must distinguish between expect declarations (pure contract) and actual implementations (side-effectful) — this is non-trivial to automate correctly and risks high false-positive rates.

• Assumption: "State machines communicate only via repository contracts" — Challenge: The AGENTS.md documents repository-mediated communication, but the actual implementation may have legitimate direct dependencies (e.g., AuthStateMachine→AppState). A rigid check could flag intentional design as violations.

---

Risk Assessment

Risk	Severity	Likelihood	Impact	Mitigation
Audit discovers violations that delay store submission indefinitely	High	Medium	Release blocked, business impact	Define a triage policy: critical violations block, minor ones get tracked but don't gate
Fitness tests produce false positives on expect/actual declarations	Medium	High	Wasted investigation time, developer frustration	Whitelist expect declarations by convention; only check actual imports
Scope creep — fitness suite becomes too ambitious for pre-release	Medium	Medium	Delays submission without clear value	Limit to 3 checks only: (1) core purity, (2) SM coupling, (3) presentation→persistence
Fitness test tooling incompatible with KMP/Gradle structure	Medium	Low	Implementation delay	Validate with a single smoke test before building full suite
Fitness tests not maintainable as codebase evolves	Low	Medium	Tests rot and get disabled	Generate checks from architecture rules in a config file, not hardcoded assertions

---

Security Concerns

• Low concern: The fitness suite itself is read-only (analyzing import graphs and dependency trees). No security surface introduced.
• Note: If the audit reveals that auth/security modules have boundary violations, that discovery itself becomes a security concern that should be fast-tracked.

---

Compliance & Debt

• Technical debt risk: If the audit uncovers significant FC&IS violations in core domain logic (e.g., PollLogic.kt importing SQLDelight), the "fix" could be a non-trivial refactor that cascades through tests. This is exactly the scenario that should be diagnosed before release but fixed after with a tracked debt item.
• No regulatory/compliance implications for this proposal itself.

---

Recommended Guardrails

1. Two-phase rollout: Phase 1 — run as a reporting tool on release/1.0.0-store-submission (CI annotation, not gate). Phase 2 — promote to hard gate on main after release, once violations are triaged and baseline is established.

2. Severity classification before gating: Define explicit criteria for what constitutes a blocking violation (e.g., domain logic importing android.*/platform.*) vs. a warning (e.g., presentation layer importing repository interfaces). Only blocking violations should prevent merge.

3. KMP-aware test harness: Use a dependency-analysis tool (e.g., Kodein dependency checker, custom Gradle task with kotlin.compiler.plugin or static analysis via detekt with custom rules) that understands expect/actual semantics. Do NOT write regex-based import checks.

4. Baseline snapshot: Run the suite once, capture results, and use that as the regression baseline. The gate should prevent new violations, not necessarily flag all pre-existing ones (those go to tech debt backlog).

5. Time-box the implementation: Cap effort at 2 days. If the fitness suite can't be built in that time on a KMP project, the ROI is wrong for a pre-release activity. Document the intent and schedule it for post-1.0.0.

6. Explicit exclusion list: State machines like AuthStateMachine that integrate with AppState are intentionally in the shell layer. Create an allowlist for known shell-to-shell dependencies so they don't trigger violations.

---

Vote

Position: for

Reasoning: The architectural boundary audit is a prudent pre-release investment — discovering FC&IS violations post-submission would be significantly more expensive. However, the proposal should be amended to run as a diagnostic report first (not a hard CI gate), with a severity-based triage policy and time-boxed implementation. The core intent is sound; the delivery mechanism needs calibration to avoid inadvertently blocking the store submission.

[guyghost]

✅ Prioritization Agent — FOR (weight: 2)

Role: Impact scoring and roadmap positioning
Duration: 96.6s

Scoring Matrix

Dimension	Score (1-10)	Justification
Business Impact	8	Prevents store rejection and catastrophic 1-star launch reviews caused by hidden architectural coupling surfacing as runtime crashes on diverse devices.
User Impact	7	Users experience fewer crashes — indirect but directly affects retention and NPS in the critical first 2 weeks post-launch.
Implementation Cost	4	Test/tooling code only, no production changes. KMP lacks an off-the-shelf ArchUnit equivalent, but import-graph analysis via Kotlin compiler APIs or Detekt custom rules is well-understood.
Risk Level	2	Read-only validation layer — zero risk of introducing regressions. Failure mode is false positives, which are cheaply fixed.
Effort Required	4	~2–3 focused days: catalog boundaries across ~6 modules, write ~25 fitness rules, wire CI gate on the release branch.
Strategic Alignment	9	FC&IS is a named architectural pillar in AGENTS.md; "Compound Engineering" mandates 40% review time; release branch is the current strategic priority.

Priority Score

Weighted Score: 4.1 / 10 (formula scale practical max ≈ 6.5; normalized ≈ 6.3)
Formula: (Impact×3 + Strategic×2 − Cost×1 − Risk×2 − Effort×1) / 7
= ((7.5)×3 + 9×2 − 4×1 − 2×2 − 4×1) / 7 = 28.5 / 7 = 4.1

Roadmap Recommendation

Placement: Now
Justification: This is a release-gate activity, not a roadmap item. Running it before store submission is the only valuable timing — post-launch audit is closing the barn door after the horse. The effort is bounded (2–3 days), risk is near-zero, and the downside of skipping it (latent coupling → production crashes → bad reviews → store rejection) is asymmetrically large. Blocking the release branch with this gate is the correct trade-off.

Opportunity Cost

• ~2–3 engineering days deferred from feature work or polish tasks on the release branch.
• If the audit uncovers violations, remediation could add 1–5 additional days — but that cost exists regardless and compounds if discovered post-launch.
• Does not delay parallel work on non-release branches.

Dependencies

• Dependency 1: Release branch release/1.0.0-store-submission must be code-frozen (or near-frozen) so the fitness suite validates the actual submission candidate, not a moving target.
• Dependency 2: CI pipeline must support a new test job on the release branch (GitHub Actions / Gradle task).
• Dependency 3: Module boundary inventory — someone must map the current core/ vs shell/ vs presentation/ packages to define fitness rules. The AGENTS.md FC&IS description provides the spec.

Vote

Position: for
Reasoning: The weighted score sits above the "against" threshold, and qualitative factors dominate: near-zero implementation risk, bounded effort, and asymmetric downside if skipped before a 1.0.0 store submission. This is exactly the kind of quality gate that should exist before users touch the app — not after.

[guyghost]

✅ Spec Writer — FOR (weight: 1)

Role: PRD, user stories, and acceptance criteria
Duration: 73.3s

PRD Summary

This proposal introduces an Architecture Fitness Test Suite — an automated, CI-enforced validation layer that verifies Functional Core & Imperative Shell (FC&IS) boundaries across the Wakeve Kotlin Multiplatform codebase. The suite will run as a CI gate on the release/1.0.0-store-submission branch and fail the build if any architectural violation is detected.

The fitness tests enforce three invariants: (1) pure domain functions in core/ must have zero imports from platform layers, SQLDelight drivers, Ktor clients, or any side-effect–producing dependency; (2) state machines (EventManagementStateMachine, ScenarioManagementStateMachine, MeetingServiceStateMachine) must communicate exclusively through repository contract interfaces, never by direct reference to concrete implementations; and (3) the presentation layer (Compose ViewModels, SwiftUI views) must not directly import or access persistence primitives (SQLDelight queries, database drivers).

The suite replaces the current manual/review-only boundary enforcement with deterministic, repeatable tests that run on every PR targeting the release branch. It acts as a "living architecture decision record" — if the tests pass, the architecture is sound; if they fail, the violation is pinpointed with file and import details.

User Stories

US-1: Pure Domain Core Boundary Enforcement

As a developer on the Wakeve team, I want an automated test that fails if any file under core/ imports platform-specific or side-effect dependencies, so that pure domain logic remains testable, deterministic, and free of hidden coupling.
Acceptance Criteria:

• AC1: A test scans all .kt files under shared/src/commonMain/kotlin/**/core/ and asserts zero imports matching a denylist: android., ios., platform., app.cash.sqldelight, io.ktor, kotlinx.coroutines.Dispatchers (unconfined OK), java., javax., kotlinx.coroutines.runBlocking.
• AC2: The denylist is configurable via a .arch-boundaries.yml file at project root, allowing additions without code changes.
• AC3: On violation, the test output lists the offending file, the violating import line, and which denylist rule it matched.
• AC4: The test runs via ./gradlew shared:jvmTest --tests "*ArchitectureFitnessTest*" and exits with non-zero code on any violation.

US-2: State Machine Repository-Only Communication

As a solution architect, I want a test that verifies state machines only depend on repository interfaces (not concrete implementations), so that the repository-mediated communication pattern remains intact and state machines stay decoupled from each other.
Acceptance Criteria:

• AC1: For each state machine class (EventManagementStateMachine, ScenarioManagementStateMachine, MeetingServiceStateMachine), the test asserts that constructor parameters and all field types are either: (a) repository interfaces from repository/, (b) standard library types, or (c) domain models from domain/.
• AC2: The test rejects direct imports of DatabaseEventRepository, SqlDelightDriver, KtorClient, or any actual implementation class within state machine files.
• AC3: The test verifies no state machine file imports another state machine file directly — all cross-machine coordination must go through the shared repository.
• AC4: A clear report lists any illegal dependency with the state machine name, the forbidden dependency, and a suggested replacement (e.g., "Use EventRepository interface instead of DatabaseEventRepository").

US-3: Presentation Layer Isolation from Persistence

As a QA engineer, I want a test that confirms ViewModels and UI composables never import persistence primitives directly, so that all data access flows through the repository abstraction layer and remains testable with mocks.
Acceptance Criteria:

• AC1: All .kt files under wakeveApp/src/commonMain/kotlin/**/viewmodel/ and wakeveApp/src/commonMain/kotlin/**/ui/ are scanned for imports matching app.cash.sqldelight, com.guyghost.wakeve.db. (SQLDelight generated), or direct Database*Repository concrete classes.
• AC2: Allowed imports include repository.* interfaces, domain.* models, statemachine.*, and services.* interfaces — but not their actual implementations.
• AC3: On violation, output specifies the ViewModel/composable, the forbidden import, and the recommended abstraction layer to use instead.
• AC4: The test distinguishes between "hard violations" (fail the build) and "warnings" (e.g., importing Dispatchers for UI thread switching) based on the .arch-boundaries.yml severity configuration.

US-4: CI Gate Integration on Release Branch

As a release manager, I want the architecture fitness tests to run automatically on every PR targeting release/1.0.0-store-submission, so that no architecturally compromised code can merge into the store-submission branch without explicit override.
Acceptance Criteria:

• AC1: A CI workflow step runs ./gradlew shared:jvmTest --tests "*ArchitectureFitnessTest*" before any merge to release/1.0.0-store-submission.
• AC2: If any fitness test fails, the PR is blocked from merging with a clear status check failure message.
• AC3: The CI step completes in under 60 seconds on a standard runner (fitness tests are source-scanning, not integration tests).
• AC4: The workflow file is versioned in .github/workflows/arch-fitness.yml and can be run locally with the same Gradle command.

US-5: Baseline Snapshot & Migration Path

As a developer inheriting this codebase, I want the fitness suite to generate a baseline report of current boundary compliance, so that I can address existing violations incrementally rather than facing a failing build with no context.
Acceptance Criteria:

• AC1: Running ./gradlew shared:jvmTest --tests "*ArchitectureBaselineReport*" produces a JSON report listing all files, their dependency category (clean / warning / violation), and specific offending imports.
• AC2: The baseline report can be checked into the repo as architecture-baseline.json and used as a "known exceptions" list — violations present in the baseline are logged as warnings, not build failures.
• AC3: New violations not present in the baseline cause immediate build failure.
• AC4: The baseline can be regenerated with ./gradlew archBaselineUpdate to accept new exceptions after team review.

Out of Scope

• Runtime dependency injection graph validation (compile-time import scanning only)
• Enforcement of naming conventions or code style rules (ktlint handles this)
• iOS Swift file boundary analysis (this iteration is Kotlin-only; Swift import analysis is a follow-up)
• Performance benchmarking or code size analysis
• Automatic refactoring suggestions beyond the text-based hints in test output
• Migration away from expect/actual pattern (only verifying it's used correctly)

Open Questions

• Q1: Should the denylist in .arch-boundaries.yml also flag kotlinx.serialization within core/? It's technically impure (reflection/codegen) but widely used for domain model serialization — team needs to decide if this is a hard boundary or an accepted exception.
• Q2: What is the team's tolerance for the baseline exception list? Should there be a cap (e.g., max 10 exceptions) after which all violations must be resolved before new features?
• Q3: Should the CI gate also run on main or only on release/1.0.0-store-submission? Running on main would catch violations earlier but adds CI time to every PR.

Vote

Position: for
Reasoning: The proposal is well-scoped and addresses a real pre-release risk — hidden architectural coupling in a codebase that has grown across 6+ phases. The FC&IS boundaries are explicitly documented in the project's AGENTS.md, making them natural candidates for automated enforcement. The baseline snapshot approach (US-5) pragmatically handles existing technical debt without blocking the release.

[guyghost]

✅ Delivery Agent — FOR (weight: 1)

Role: Implementation planning and execution
Duration: 59.5s

Implementation Phases

Phase 1: Architecture Discovery & Boundary Mapping (Week 1, Days 1-2)

• Task 1.1: Inventory all commonMain modules — list every file under core/, shell/, presentation/, repository/, services/ — Effort: 3h
• Task 1.2: Map the intended FC&IS boundaries per the project's AGENTS.md — document which packages are "core" (pure), "shell" (side-effects), and "presentation" — Effort: 2h
• Task 1.3: Run a manual import audit — grep all import statements in core/domain files for platform or SQLDelight imports to establish the current violation baseline — Effort: 3h
• Task 1.4: Document state machine communication paths — trace EventManagement ↔ ScenarioManagement ↔ MeetingService to confirm repository-mediated pattern — Effort: 2h

Phase 2: Fitness Function Implementation (Week 1, Days 3-5)

• Task 2.1: Add archunit or custom Kotlin fitness tests to shared/src/commonTest/kotlin/architecture/ — Effort: 4h
• Task 2.2: Implement Core Purity Rule test — assert that no file under core/ or domain/ imports android.*, ios.*, sqldelight.*, ktor.*, io.* (side-effect packages) — Effort: 3h
• Task 2.3: Implement State Machine Isolation Rule test — assert that state machine files (*StateMachine.kt) only import repository interfaces, never concrete implementations or other state machines directly — Effort: 3h
• Task 2.4: Implement Presentation-Persistence Boundary test — assert that Compose/SwiftUI files (ui/, Views/) never import sqldelight.* or DatabaseEventRepository directly — Effort: 2h
• Task 2.5: Implement expect/actual Contract Rule test — assert that expect declarations live only in commonMain and actual implementations live only in platform-specific source sets — Effort: 2h

Phase 3: Violation Remediation (Week 2, Days 1-3)

• Task 3.1: Fix all violations discovered by fitness tests — extract side-effect code from core functions into shell wrappers, introduce repository interfaces where missing — Effort: 6h (estimate; actual depends on audit findings)
• Task 3.2: Add integration test verifying full DRAFT→FINALIZED workflow still passes after refactoring — Effort: 2h
• Task 3.3: Run full test suite (./gradlew shared:test) and confirm 36+ tests still green — Effort: 1h

Phase 4: CI Gate Integration (Week 2, Days 4-5)

• Task 4.1: Add Gradle task archFitnessTest that runs architecture boundary tests as a distinct test category — Effort: 2h
• Task 4.2: Configure CI pipeline (GitHub Actions or equivalent) to run archFitnessTest as a required check on release/1.0.0-store-submission — Effort: 2h
• Task 4.3: Add pre-commit hook option for local boundary enforcement — Effort: 1h
• Task 4.4: Document the fitness rules in docs/architecture-boundaries.md for future contributors — Effort: 1h

Branch Strategy

• Main branch: release/1.0.0-store-submission (target release branch)
• Feature branches: tech/arch-fitness-audit (short-lived, merge within sprint)
• Review process: PR with all fitness tests visible → architect review → merge to release branch

CI/CD Changes

• Pipeline change 1: Add arch-fitness job — runs ./gradlew shared:jvmTest --tests "*ArchitectureBoundaryTest*" as a required gate on PRs to release branch
• Pipeline change 2: Add boundary test count to build summary — fail if expected test count drops below N (prevents silent removal)
• Pipeline change 3: Dependency graph verification step — fail if new imports violate declared boundary rules

Blockers & Dependencies

Blocker	Owner	ETA	Impact if Delayed
Unknown number of existing violations	Dev team	Day 2	Remediation phase could expand from 6h to 20h+
No ArchUnit-Kotlin in current dependencies	DevOps	Day 3	Would require custom reflection-based checks instead (more effort, less maintainable)
CI pipeline access (GitHub Actions?)	DevOps	Day 4	Manual gate only; no automated enforcement
Release branch merge freeze window	Release mgr	Day 5	Must complete before code freeze

Rollback Plan

All fitness tests are additive — they assert constraints on existing code. If the tests are wrong (false positives), they can be disabled via Gradle property excludeArchFitness=true without touching production code. Remediation changes (Phase 3) are structural refactors with full test coverage; revert via git revert on the feature branch if regression detected.

Timeline Summary

Phase	Duration	Start	End
Discovery & Mapping	2 days	Apr 16	Apr 17
Fitness Function Impl	3 days	Apr 18	Apr 22
Violation Remediation	3 days	Apr 23	Apr 25
CI Gate Integration	2 days	Apr 28	Apr 29

Total Estimated Duration: ~2 weeks (10 working days)

Vote

Position: for
Reasoning: This is a high-value, bounded-scope technical investment that directly de-risks the 1.0.0 store submission. The KMP codebase with 6+ phases of organic growth makes boundary violations a statistical certainty; catching them now via automated fitness tests is far cheaper than debugging production crashes post-release. Phases 1-2 can ship within a week and provide immediate value even without CI integration.

[guyghost]

✅ Power User (Dev) — FOR (weight: 1)

Role: Advanced user perspective — daily usage, production workflows
Duration: 32.1s

First Impression

This proposal makes my life better — a fitness test suite that catches boundary violations before they become 3 AM debugging sessions is exactly the kind of guardrail I want on a release branch.

What Works for Me

• CI gate on release branch: I've been bitten by hidden coupling between state machines before. Having this as an automated check means I don't have to manually trace imports through 6 phases of accumulated code every time I touch EventManagementStateMachine or PollLogic. Set it and forget it.
• Zero-import enforcement for pure domain: The PollLogic.kt scoring functions and domain validators should absolutely never touch SQLDelight or platform APIs. A test that fails the build when someone imports android.os.* in commonMain core saves me from review regressions that slip through in large PRs.
• Repository-mediated communication check: The project AGENTS.md explicitly defines this pattern but there's nothing enforcing it. A fitness test that flags direct cross-state-machine calls catches the exact coupling pattern that causes race conditions in offline sync scenarios.

What Concerns Me

• Scope creep on "release branch": In production, a CI gate that's too aggressive could block a hotfix because CalendarService.ios.kt has a transitive import through some Ktor dependency. The test suite needs a clear allowlist for expect/actual patterns — the whole point of that architecture is that commonMain declares the boundary and androidMain/iosMain implements it. If the fitness test doesn't understand that distinction, it will fire false positives constantly.
• No mention of incremental rollout: Running this on the entire codebase at once on a release branch could surface dozens of violations. Without a triage plan (block vs. warn vs. suppress), this becomes a gate that nobody can pass. — "In production, this could delay the 1.0.0 store submission by days while we debate whether AuthStateMachine.kt importing TokenStorage is a shell concern or a core violation."

What's Missing

If this proposal doesn't address graduated enforcement (e.g., block on clear violations in core/, warn on ambiguous cases in shell/, with @SuppressBoundary annotations for documented exceptions), it's incomplete. Also missing: how this interacts with the existing 36+ tests — does the fitness suite run alongside them or as a separate CI stage? And what about the expect/actual pattern specifically — the fitness test must understand that expect class CalendarService in commonMain is a declaration, not a violation.

Vote

Position: for
Reasoning: This is a net-positive guardrail that catches real risk — organic growth across 6 phases has almost certainly introduced at least a few boundary leaks, and finding them after store submission is orders of magnitude more painful than catching them in CI. Just needs clear scoping: focus enforcement on core/ purity first, treat shell/ violations as warnings, and make sure expect/actual declarations are exempt.

[guyghost]

✅ Casual User (PM) — FOR (weight: 1)

Role: Occasional user perspective — simplicity, clarity, time-to-value
Duration: 30.0s

Bottom Line

Yes, do this — it's an automated safety net that catches hidden bugs before they hit real users on the app stores.

Why I Like It

• Prevents store rejection disasters: A crash caused by tangled architecture in production is the worst kind of problem — hard to reproduce, hard to fix, and it damages user trust immediately. This catches those issues before submission.
• Runs itself once set up: It's a CI gate, not a manual checklist. Nobody has to remember to run it. Every commit on the release branch gets checked automatically — zero ongoing effort from the team.
• Cheap insurance for 1.0.0: You only get one chance to make a first impression on the App Store and Google Play. A boundary violation that causes a crash in a specific device/OS combination is exactly the kind of thing that slips through manual testing.
• Pays dividends beyond launch: Once this fitness test suite exists, it protects every future phase too. New agents (Transport, Notifications, etc.) will be automatically checked against the same rules.

Why I'm Worried

• "Architecture fitness test suite" sounds like it could take a sprint to build: If this turns into a massive engineering effort that delays the store submission by weeks, we've defeated the purpose. It needs to be scoped tightly — run the audit, fix the violations, ship.
• False positives could block the release: If the tests are too strict or misconfigured, they could flag legitimate code and create a bureaucratic bottleneck right when we're trying to ship. The pass/fail criteria need to be crystal clear.
• Team adoption risk: If the test failures produce cryptic messages like "FC boundary violation in module X," nobody will know what to do. The output needs to be human-readable.

What I'd Change

Add a deadline and a kill switch. Scope this to: (1) run the boundary audit on the current codebase, (2) fix any real violations found, (3) set up the CI gate with a clear timebox of 2-3 days max. If the suite isn't ready by then, we ship without it and add it in the first patch release. The audit itself is valuable even without the CI automation.

Also: make sure every test failure outputs a plain-English explanation and a suggested fix — not just a stack trace. If a PM can't understand why the build failed, it's not ready.

Vote

Position: for
Reasoning: It's cheap insurance for our biggest milestone. The risk of shipping latent architectural coupling to real users on two app stores outweighs the few days of engineering time to set this up. Just keep it scoped tight and don't let it become a rabbit hole.

[guyghost]

✅ New User (Skeptic) — FOR (weight: 1)

Role: Fresh user perspective — onboarding, learning curve, first impressions
Duration: 33.6s

Honest Take

This feels like the kind of proposal that sounds obviously important but I'd need to see whether it actually catches real problems or just adds ceremony before a release.

What Makes Sense to Me

• Point 1: The reasoning is honest — the codebase grew across 6+ phases without systematic boundary checks. That's exactly how coupling sneaks in. "We built fast, now verify" is a legitimate pre-release concern.
• Point 2: Running it as a CI gate on the release branch means it's not just a one-time audit doc nobody reads — it'll actually block bad merges. That's the kind of thing that makes a tool valuable (enforcement, not just reporting).
• Point 3: The three rules (pure domain = zero side-effect imports, state machines talk via repository contracts, presentation ≠ persistence) are concrete enough that I can understand what "passing" looks like. That's good — I'd know if it worked.

What Confuses Me

• Confusion 1: "Architecture fitness test suite" — is this static analysis? Runtime tests? A custom Gradle plugin? The proposal says what it should check but not how. Am I supposed to write ArchUnit-style dependency rules? Parse import statements? Something else? That matters a lot for scope.
• Confusion 2: The proposal says "hidden coupling between state machines" but the AGENTS.md already describes repository-mediated communication as the explicit pattern. If the team designed it that way, what's the actual risk level? Is this theoretical hygiene or has someone actually seen a violation? Without evidence of a real problem, this feels like it could be a lot of work for a "clean bill of health."
• Confusion 3: "Expect/actual pattern" and "FC&IS" are jargon I'd need to go look up. The proposal assumes I know what these mean. For something being pitched as a release blocker, I'd want clearer language about what specifically could break in production.

What I'd Tell a Friend

This proposal would make me slightly more confident in the tool's process — it's the kind of thing a good tech lead would insist on before a store release. But I'd want to know: is this a day of work or a week? If it's a lightweight static analysis check, great. If it's building a whole custom testing framework, that's scope creep right before a release, which feels risky in itself.

Vote

Position: for

Reasoning: The intent is sound — verify architectural boundaries before shipping 1.0.0. But I'm voting "for" with a caveat: this needs a clear scope definition. If it turns into "build a custom architecture validation framework," that's a trap right before release. Start with the simplest thing that catches real violations (maybe even just import analysis on the core package) and ship that. Don't let perfect be the enemy of shipped.