movies-diary/docs/adr/0007-no-repositories-in-presentation.md

AppContext carries no Repositories; composition is a dev-only dependency of presentation

ADR-0006 closed sixteen call sites where a presentation handler called a repository method directly, but explicitly left AppContext.repos in place: ~40 sites still read state.app_ctx.repos.<field>.clone() to pass an Arc positionally into a use case that took individual params rather than a deps struct, and migrating all of them at once would have made ADR-0006's handler-extraction change harder to review and revert independently. check-handler-repos was written narrowly on purpose, forbidding only the direct-call bypass ADR-0006 closed, not the clone-and-pass pattern this plan (Plan C2) exists to remove.

Plan C2 did that migration in five tasks. Tasks 1-3 converted the 23 use cases the plan's initial audit found reading an Arc cloned from Repositories — across integrations/webhook, wrapup, watchlist, import, users, movies, goals, auth, and search — from individual Arc parameters to a single &FooDeps struct each, registered on application::Deps and constructed by composition::build_deps, following the convention ~30 other use cases already used. Task 4 replaced the last two direct repository calls in the codebase — extractors.rs's AdminApiUser and AdminUser both called repos.user.find_by_id(...) inline to check admin status — with a new users::authorize_admin use case, closing the gap ADR-0006 honestly scoped as handlers-only (these were two axum extractors, not handler functions).

Task 5 widened check-handler-repos from handlers/ to all of crates/presentation/src, and reported zero offenders. That measurement was wrong. Its pattern was repos\.[a-z_]+\.clone\(\) — built to catch the clone-and-pass shape the plan had inventoried — and it could not see two other shapes present in the same tree: a bare reference passed by argument (&state.app_ctx.repos.diary, no .clone() anywhere) and a let-bound access (if let Some(ref fed_query) = ...repos.federated_profile, followed by a method call on the binding rather than on repos itself). diary::get_diary, diary::get_review_history, and diary::export_diary all took their repository argument by reference rather than owned, so their three call sites (handlers/diary.rs, handlers/rss.rs, handlers/movies.rs, handlers/helpers.rs) were structurally invisible to a regex anchored on .clone(). handlers/users.rs's federated-profile lookup bound repos.federated_profile with if let and called .get_federated_profile(...) on the bound variable, which no repos.<field>.<method>( pattern can match across a let. The first attempt at this task found the five live sites by inspection when it went to delete the field the guard was meant to make safe to delete, and correctly returned blocked rather than deleting AppContext.repos out from under them; a new Task 7 then converted all five (plus a sixth, non-repos internal caller broken purely by get_diary's signature change) before this attempt at Task 6 ran.

Decision

AppContext no longer has a repos field, and presentation no longer depends on composition in production. pub repos: Repositories and the pub use composition::Repositories; re-export are both deleted from crates/presentation/src/context.rs. There is no route by which any code in crates/presentation/src (outside src/tests/, which builds its own Repositories purely to drive composition::build_deps for test fixtures) can reach a repository directly — not a stored field, not an import, not a re-export. Every dependency a handler or extractor needs now comes from state.app_ctx.deps, a prebuilt Arc<application::Deps> assembled once at the composition root.

crates/presentation/Cargo.toml moves composition from [dependencies] to [dev-dependencies]. After the field deletion, composition is referenced only from src/tests/extractors.rs, which calls composition::build_deps to produce a real Deps for test fixtures — a legitimate use of the composition root's public API, just not one production code needs. Confirmed both ways: cargo tree -p presentation -e normal --depth 1 shows no composition anywhere in the production dependency tree; cargo tree -p presentation -e dev --depth 1 shows it as a direct dev-dependency. crates/server (ADR-0006's home for the binary and every backend-selection feature) already depended on composition directly in [dependencies] — that entry is untouched by this task — because it is the actual composition root, not presentation. It still builds a Repositories and still needs AppContext { deps, .. } without a repos field, so this task's field deletion required two small production-adjacent fixes outside crates/presentation that no earlier task in this plan touched: crates/server/src/main.rs::wire_dependencies (production) and crates/server/tests/api_test.rs (its integration-test harness) both used to write presentation::context::{AppContext, Repositories} and construct AppContext { repos, deps, .. }; both now import Repositories from composition directly and drop repos from the struct literal, keeping the local repos binding alive only long enough to pass &repos into composition::build_deps, the same pattern presentation's own test helper uses.

All use cases that used to read an Arc out of AppContext.repos — 23 converted in Tasks 1-3, three more (get_diary, get_review_history, export_diary) converted in Task 7 once the guard's blind spot surfaced them, plus two newly-created use cases (users::authorize_admin in Task 4, users::get_federated_profile in Task 7) — now take a single deps struct. The two extractors.rs admin checks (AdminApiUser, AdminUser) both now call users::authorize_admin::execute, returning Result<Option<bool>, DomainError> so "user not found" and "repository call failed" stay distinguishable by construction rather than by pattern-matching a DomainError variant an adapter happens not to raise today. handlers/users.rs's federated-profile branch now calls users::get_federated_profile::execute, which mirrors Repositories::federated_profile's own Option-typed optionality (federation can be configured off) rather than inventing a new way to say "this binary doesn't need it." Both migrations preserve their call sites' exact rejection behavior on every path (missing port, repository error, empty result, found result) — verified path-by-path against the pre-migration code in Task 4's and Task 7's own reports, not asserted here.

Two use cases remain on individual params, correctly, because they were never reachable through AppContext.repos in the first place: movies::request_enrichment::fetch_if_stale and movies::enrich_movie::execute, both called only from MovieEnrichmentHandler (crates/application/src/movies/event_handler.rs), a domain::ports::EventHandler implementor that the composition root constructs directly with individual Arc fields, the same way any adapter is wired — never through state.app_ctx.deps. fetch_if_stale takes fully individual parameters (&dyn MovieEnrichmentClient, &Arc<dyn MovieProfileRepository>, plus two value params). enrich_movie::execute actually does take a struct, EnrichMovieDeps — but one built locally inside MovieEnrichmentHandler::handle from its own already-held Arc fields, not a struct registered on application::Deps or constructed by composition::build_deps. Neither shape is what this ADR means by "use cases now take deps structs"; both are correctly out of scope for the same reason Services- sourced use cases are (see below), and the plan's original note that they're "adapter-called, don't migrate them" holds up.

This ADR's "use cases take deps structs" claim is scoped to what Plan C2 touched: use cases that used to read AppContext.repos. It is not a claim that every execute function in the codebase takes an application::Deps-registered struct. Two examples outside that scope, found while fact-checking this ADR, are worth naming so nobody mistakes their shape for a regression: diary::log_review::execute is called directly by two presentation handlers (handlers/diary.rs::post_review and ::create_review) with an individual &state.app_ctx.services.review_logger argument — legitimate, because review_logger comes from AppContext.services, a field this plan never touched, not from repos. wrapup::compute::execute, import::cleanup::execute, and integrations::cleanup::execute also take individual params, but none of the three is ever called from a presentation handler — compute is called internally by wrapup::handle_requested, and the two cleanup use cases are called only from crates/application/src/jobs/, the background-job runner. All four were outside Plan C2's stated scope before this task started and remain untouched by it.

check-handler-repos is now a single whole-crate rule: any mention of app_ctx.repos outside src/tests/ is an offender. The two-pass shape-matching regex (repos.<field>.<method>(, repos.<field>.clone().<method>() is gone. It is gone because it is no longer needed, not because it was simplified for its own sake: with AppContext.repos deleted, there is no shape of legitimate production access left to distinguish from an illegal one — no clone-as-argument to permit, no direct call to forbid separately. A single substring match is sufficient and, unlike the old guard, unevadeable: it cannot be blind to a reference pass or a let-binding the way the shape-matching guard demonstrably was (see above), because it does not attempt to parse the shape of the access at all — it only asks whether the now-nonexistent field is mentioned. Verified by injecting app_ctx.repos.user into extractors.rs (a non-test production file) and confirming make check-handler-repos fails, naming the exact file and line, before reverting.

Considered Options

• Leaving the shape-matching two-pass guard in place, just widened to the whole crate — this is what Task 5 actually did, and it is what let three reference-pass sites and one let-binding site through with a clean ✅. Once repos no longer exists, keeping the old guard's shape-matching would mean maintaining two regex passes to catch a category of mistake (any mention at all) that a single grep already catches completely. Rejected as strictly worse than the simple rule, not merely equivalent to it.
• Deleting check-handler-repos entirely, since the compiler now enforces the invariant — a production file referencing app_ctx.repos simply fails to build once the field is gone, so the guard is redundant with cargo build in the narrow sense of "will this compile." Rejected because the guard is cheaper to run (grep vs. a full workspace build) for make check's fast-path checks, and because it fails with a direct "here's the offending line" message rather than a compiler error several frames removed from the actual mistake (e.g. a struct-literal error at the AppContext construction site rather than at the stray reference itself).

Known follow-ups, out of scope here

• Plan D inverts ActivityPubPort so presentation drops its one remaining adapter dependency, activitypub — untouched by this plan, exactly as ADR-0006 recorded.
• The pre-existing follow_backfill_handler.rs federation-gate bug and the isolated cargo test -p composition worker_deps_wiring failure (both recorded in ADR-0006) are unaffected.
• diary::log_review, wrapup::compute, import::cleanup, and integrations::cleanup remain on individual params, correctly — none of them ever read from AppContext.repos, so none was ever in this plan's scope. Whether they should eventually move to deps structs for consistency with the rest of the codebase is a separate, unstarted question this ADR takes no position on.
• CONTRIBUTING.md's architecture rules were updated in this same commit to stop describing use cases as taking &AppContext (a claim already false before this plan) and instead describe the &FooDeps-struct convention this ADR documents.