Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@Anlab.Core/Domain/TestItem.cs`:
- Around line 34-35: The TestItem domain model's TestGroup property lacks the
[Required] attribute while the database marks that column as non-nullable, so
add the [Required] attribute to the TestGroup property in the TestItem class
(public string TestGroup { get; set; } = string.Empty;) to enforce validation
earlier; also ensure the System.ComponentModel.DataAnnotations namespace is
imported if not already.
- Around line 37-41: The TestGroups computed property is missing the [NotMapped]
attribute and EF Core will try to map it; add the [NotMapped] attribute above
the TestGroups property (the string[] TestGroups getter/setter that wraps
TestGroup and uses Split/Join) to match the Categories pattern so EF Core
ignores this computed array property during model building.

In `@Anlab.Sql/dbo/Tables/TestItems.sql`:
- Line 13: The new NOT NULL constraint on the TestItems.TestGroup column will
fail on populated DBs; add a safe rollout migration that (1) alters TestItems to
add TestGroup as NULL or with a temporary DEFAULT, (2) backfills existing rows
with a valid value (e.g. empty string or a sentinel) via an UPDATE, and then (3)
alter the column to NOT NULL and remove any temporary default; reference the
TestItems table and TestGroup column when implementing the migration and ensure
the backfill value matches application expectations.

---

Nitpick comments:
In `@Anlab.Sql/dbo/Tables/TestItems.sql`:
- Line 13: The TestItems table's [TestGroup] NVARCHAR(64) currently accepts any
string; add a CHECK constraint (e.g., name it CK_TestItems_TestGroup) on the
[TestGroup] column to only allow the supported set of group values used by
filtering logic (replace the placeholder list with the actual allowed values),
and deploy the constraint alongside the table definition so invalid values are
rejected at insert/update time.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@Anlab.Sql/dbo/Tables/Orders.sql`:
- Line 21: The Orders table's IsDeleted column is declared as BIT NOT NULL
without a default which breaks inserts that don't supply it; update the Orders
table schema so IsDeleted has a DB-level default of 0 (e.g., add a DEFAULT 0
constraint on the IsDeleted column) to preserve backward-compatible inserts and
consider adding a migration/ALTER TABLE to apply the default for existing
databases; keep the column name IsDeleted and the table name Orders when
locating the change.
- Line 4: The schema sync removed foreign key constraints and a default value
causing data-integrity and INSERT issues; restore the FK constraints linking
Orders.CreatorId to the Users (or appropriate principal) table and
Orders.ApprovedPaymentTransaction_Id to the PaymentTransactions (or appropriate
principal) table by adding back the corresponding ALTER TABLE ... ADD CONSTRAINT
... FOREIGN KEY declarations (use the original constraint names if known), and
restore the DEFAULT ((0)) for the Orders.IsDeleted column so inserts that omit
IsDeleted work; update the Orders table DDL around the columns
ApprovedPaymentTransaction_Id, CreatorId and IsDeleted and ensure the related
indexes on those columns are present (recreate any dropped indexes referenced in
the diff) so the soft-delete and FK-dependent views and logic continue to work.

---

Outside diff comments:
In `@Anlab.Sql/dbo/Tables/History.sql`:
- Around line 3-12: The table definition for History is missing a foreign key
from History.OrderId to dbo.Orders(Id), allowing orphaned rows; add a FOREIGN
KEY constraint (e.g., CONSTRAINT FK_History_OrderId FOREIGN KEY ([OrderId])
REFERENCES dbo.Orders([Id]) ) to the History table definition (alongside or
after CONSTRAINT [PK_History]) so History.OrderId enforces referential integrity
and choose the appropriate ON DELETE/ON UPDATE behavior for your domain.

In `@Anlab.Sql/dbo/Tables/MailMessages.sql`:
- Around line 6-15: MailMessages.OrderId is missing a foreign-key constraint;
add a FK from MailMessages.OrderId to dbo.Orders(Id) by adding a constraint such
as CONSTRAINT [FK_MailMessages_Orders_OrderId] FOREIGN KEY ([OrderId])
REFERENCES [dbo].[Orders] ([Id]) (optionally with an ON DELETE/UPDATE action you
want) to the CREATE TABLE for MailMessages (near CONSTRAINT [PK_MailMessages]
and the existing FK to AspNetUsers) or implement as an ALTER TABLE ... ADD
CONSTRAINT if changing the existing table.