Reacture/FoxOffice

Fox Office is a cinema management system that provides both a public-facing API and an administrative web interface for managing theaters, movies, and screenings. It utilizes an Azure-based infrastructure with a message bus and Cosmos DB for data persistence, supported by a .NET Core architecture that includes domain models, command handlers, and comprehensive unit testing.

The application is initialized with a complete set of core components. This includes the API controllers for managing theaters, movies, and screenings, alongside the domain models and command handlers that process these requests. The infrastructure layer is also introduced, featuring Azure-based message bus and Cosmos DB repositories for the read model, as well as an initializer that sets up the required storage queues and database collections on startup.

(repo-wide) · high confidence

The FoxOffice.Admin application is introduced, providing a web-based administrative interface for managing movies, theaters, and screenings. The update adds controllers and views for creating and listing movies, theaters, and screenings, along with the necessary view models and an API client to communicate with the backend services.

source/FoxOffice.Admin · high confidence

A change to existing behaviour in contents — 2 commits, 3 files.

contents · medium confidence · unverified

Added comprehensive unit tests for the admin controllers (Movies, Theaters, Commands, and Queries), the ApiClient service, and the domain models (Movie, Theater, and their respective command handlers). These new tests verify controller actions return correct result types and models, ensure the API client correctly serializes commands and handles success/error responses, and confirm that domain aggregates raise the expected events and enforce validation rules.

source/FoxOffice.Tests · high confidence

The FoxOffice solution is initialized with ten new .csproj files defining the build configuration for each project, including Admin, Api, Azure, Contracts, Domain, Modules, Processor, ReadModel, and the two test projects. These files establish the .NET Core 2.1 and .NET Standard 2.0 target frameworks and declare the initial set of NuGet package dependencies, such as Autofac, Khala libraries, StyleCop, and various Microsoft and third-party packages.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 64 → 66 (+1.5)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 74 → 74 (-0.1)
• Architecture 88 → 89 (+0.4)
• Maturity 78 → 78 (+0.0)
• Readiness 64 → 64 (+0.0)
• Security 60 → 64 (+3.4)
• Accessibility 63 → 63 (+0.0)

• Bounded contexts not declared
• Build did not complete in the analyzer
• Duplicate intent: Both commands add a screening. AddScreening includes a ScreeningId while AddNewScreening does not, creating ambiguity about ID generation.
• Duplicate intent: Both commands create a movie. CreateMovie includes a MovieId while CreateNewMovie does not, suggesting one is for pre-allocated IDs and the other for auto-generated IDs, but the naming is ambiguous.
• Duplicate intent: Both commands create a theater. CreateTheater includes a TheaterId while CreateNewTheater does not, creating confusion about which to use.
• High CVE: Microsoft.AspNetCore.App 2.1.1
• High CVE: Microsoft.AspNetCore.App 2.1.1
• High CVE: Microsoft.AspNetCore.App 2.1.1
• High CVE: Microsoft.AspNetCore.App 2.1.1
• High CVE: Microsoft.AspNetCore.App 2.1.1
• High CVE: Microsoft.AspNetCore.Identity 2.1.1
• High CVE: Microsoft.AspNetCore.Identity 2.1.1
• High CVE: Microsoft.AspNetCore.Server.Kestrel.Core 2.1.1
• High CVE: Microsoft.AspNetCore.Server.Kestrel.Core 2.1.1
• High CVE: Microsoft.NETCore.App 2.1.0
• High CVE: Microsoft.NETCore.App 2.1.0
• High CVE: Microsoft.NETCore.App 2.1.0
• High CVE: Microsoft.NETCore.App 2.1.0
• High CVE: System.Net.Security 4.0.0
• High CVE: System.Net.Security 4.0.0
• …and 18 more

• Duplicate intent with confusing naming. 'AddNewScreening' and 'AddScreening' appear to be the same operation. 'AddNewScreening' omits the ScreeningId (likely generated by the system), while 'AddScreening' requires it. This creates ambiguity about whether the client or server generates the ID, and the naming convention is inconsistent.
• Duplicate intent with confusing naming. 'CreateMovie' includes a 'MovieId' property, while 'CreateNewMovie' does not. This suggests one is for client-generated IDs and the other for server-generated IDs, but the naming ('Create' vs 'CreateNew') does not clearly distinguish this technical difference, leading to potential misuse.
• Duplicate intent with confusing naming. 'CreateTheater' includes a 'TheaterId' property, while 'CreateNewTheater' does not. Same issue as with Movies: ambiguous ID generation responsibility masked by inconsistent naming.
• Duplicated block (16 lines × 2) (source/FoxOffice.Azure/ReadModel/DataAccess/ScreeningEntity.cs)
• Duplicated block (8 lines × 2) (source/FoxOffice.Api/Startup.cs)
• Duplicated block (9 lines × 2) (source/FoxOffice.Admin/Services/ApiClient.cs)
• End-of-life runtime: .NET netcoreapp2.1
• High CVE: Microsoft.AspNetCore.App 2.1.1
• High CVE: Microsoft.AspNetCore.Identity 2.1.1
• High CVE: Microsoft.NETCore.App 2.1.0
• High CVE: System.Net.Security 4.0.0
• Inconsistent verb prefixing in command names: 'CreateNew' is used for Movie and Theater, while 'AddNew' is used for Screening. 'Add' and 'Create' are semantically distinct in this codebase (e.g., Movie.AddScreening vs Theater.Create), but the command naming convention should be consistent within the Commands namespace.
• Type duplication across domains. 'FoxOffice.Seat' (in Contracts) and 'FoxOffice.ReadModel.Seat' have identical structure (Row, Column, IsReserved). This suggests unnecessary duplication of a value object between the command/event contract space and the read model space, increasing maintenance burden.

• Unchanged — 13 HTTP endpoints

• Unchanged — 2 containers · 2 contexts · 1 edges

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

Reacture/FoxOffice was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.