cesnimda/jobtrackingapp
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

feat(workspace): unified application checklist (Phase 5 milestone 2)
CI and Deploy / test (push) Failing after 1m8s
Details
CI and Deploy / deploy (push) Has been skipped
Details

Browse Source 
Evolve the existing readiness workflow into one persisted, user-controlled
checklist rather than adding a second tracker.

ApplicationChecklistItem records only completion state and user intent. Each
default system item carries a stable SystemKey and an AutoSignal — the same
signal /readiness already computed — and re-syncs on every read: a satisfied
signal auto-completes the item, a reverted signal reopens it, and a manual tick
always wins. Users can add, reorder, dismiss and delete.

Readiness is refactored into a projection of the checklist (score = completion
percentage, completed/missing = live items by status). Its DTO shape and the
workflowSignal/reminders health view are unchanged, so no API contract breaks.

The workspace's next recommended action now comes from the first pending
checklist item in category priority order (preparation, submission, follow-up,
interview, custom), replacing the parallel ruleset — so the overview can never
recommend something already ticked off, and a user's own task can be next.

The table follows the established MariaDB-safe path: the scaffolded migration is
a no-op and the idempotent reconciler owns the DDL for both providers. Verified
on MariaDB 11 — auto_increment PK, varchar/datetime(6)/tinyint(1) columns, both
indexes inside the key limit, cascade delete, unique system key per application,
and NULL system keys not colliding for custom items.

329 backend tests, 94 frontend tests, type check, production build and both
Docker builds pass locally.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
cesnimda
2026-07-19 11:15:46 +02:00
parent e55a6e86b7
commit 3a906b881e
18 changed files with 3783 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Data/JobTrackerContext.cs
+26
View File
@@ -45,6 +45,7 @@ namespace JobTrackerApi.Data
public DbSet<CvVariant> CvVariants => Set<CvVariant>();
public DbSet<CvVariantVersion> CvVariantVersions => Set<CvVariantVersion>();
public DbSet<AiInteraction> AiInteractions => Set<AiInteraction>();
public DbSet<ApplicationChecklistItem> ApplicationChecklistItems => Set<ApplicationChecklistItem>();
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
@@ -340,6 +341,31 @@ namespace JobTrackerApi.Data
.WithMany()
.HasForeignKey(x => x.JobApplicationId)
.OnDelete(DeleteBehavior.Cascade);
// Phase 5 Milestone 2: the application checklist — a workflow guidance layer over the existing
// readiness signals, not a second store of truth. Same deny-on-null tenant filter; cascades with
// the application. docs/architecture/application-workspace.md.
modelBuilder.Entity<ApplicationChecklistItem>()
.HasQueryFilter(x => CurrentUserId != null && x.OwnerUserId == CurrentUserId);
// varchar (not longtext) for the indexed columns — see the CvVariant note above.
modelBuilder.Entity<ApplicationChecklistItem>().Property(x => x.OwnerUserId).HasMaxLength(255);
modelBuilder.Entity<ApplicationChecklistItem>().Property(x => x.SystemKey).HasMaxLength(64);
modelBuilder.Entity<ApplicationChecklistItem>().Property(x => x.AutoSignal).HasMaxLength(64);
modelBuilder.Entity<ApplicationChecklistItem>().Property(x => x.Category).HasMaxLength(32);
modelBuilder.Entity<ApplicationChecklistItem>().Property(x => x.Status).HasMaxLength(32);
modelBuilder.Entity<ApplicationChecklistItem>().Property(x => x.Section).HasMaxLength(64);
modelBuilder.Entity<ApplicationChecklistItem>().Property(x => x.Title).HasMaxLength(255);
// Seeding is idempotent per (application, system key) — the unique index is what enforces it.
modelBuilder.Entity<ApplicationChecklistItem>()
.HasIndex(x => new { x.JobApplicationId, x.SystemKey })
.IsUnique();
modelBuilder.Entity<ApplicationChecklistItem>()
.HasIndex(x => new { x.OwnerUserId, x.JobApplicationId, x.SortOrder });
modelBuilder.Entity<ApplicationChecklistItem>()
.HasOne(x => x.JobApplication)
.WithMany()
.HasForeignKey(x => x.JobApplicationId)
.OnDelete(DeleteBehavior.Cascade);
}
// Common config for CareerProfile's relational children. The 1:many FK + cascade delete is