[Tracking] Automated codebase quality audit — 2026-07-03

Tracking issue for the automated codebase quality audit run on 2026-07-03. 50 issues filed (#374-#423). No GitHub Projects (v2) board was created — the connected GitHub MCP tools in this session expose issue/PR operations and org-level issue fields (Priority/Effort/dates) but no Projects-board (`create_project`/`add_item_to_project`) capability. This issue serves as the tracking surface instead; a real Project board can be created manually and these issues added to it (`gh project item-add` or the UI) if wanted.

## Sequencing plan

**Tier 0 — Security (fix first, independent of each other):**
- #374 AgentEndpointActor cross-tenant fallback
- #375 JS getConfiguration DisallowedSections bypass
- #376 OpenTelemetryRedactor trace-name bypass
- #377 Duplicated management API-key auth
- #406 AspNetCoreIdentityPrincipalFactory role-permission no-op

**Tier 1 — High-severity correctness bugs, mostly independent (parallelizable, one file/handler each):**
Data-loss/hang risk: #378 (Elsa3 import), #379 (fault propagation hang), #382 (Flowchart state growth), #396 (cache invalidation race), #410 (container-scope race), #409 (dead reference handler)
Request/response correctness: #383 (OutputArgument binding), #384 (PageArgs), #385 (reconciliation null FullName), #386 (checkpoint store misclassification), #387 (Execute.cs 500), #388 (XML parser), #389/#390 (zip archive), #391 (agent proposal swallow), #392 (TenantAgnostic), #393 (404 vs 500, systemic — touches shared base classes, do before other API handler fixes), #398 (test-run store expiry), #399 (checkpoint validation), #400/#401 (mediator dispatch), #402 (background publisher), #403 (structured-logs prune), #404 (version lock), #405 (task manager), #407 (Jint cast), #408 (variable naming), #411 (structured-logs async+SSE)
Performance/leak: #380 (ambient scope), #381 (Do/While validation), #394 (EFCore semaphore), #395 (DbContext leak)

**Dependency notes:**
- #393 (404-vs-500 base class fix) should land before/alongside any other Design/Runtime API handler work, since #385, #392 touch handlers in the same families.
- #400/#401 (Mediator) and #412 (scheduler-handler DRY) both touch handler-dispatch infrastructure — stack these, don't parallelize against each other.
- #382 (Flowchart pruning) and #413 (Flowchart/ControlFlow DRY batch) touch the same files — stack.
- #403/#411 (StructuredLogs) and #421 (Diagnostics DRY batch) touch the same store — stack.

**Tier 2 — Tech-debt/DRY batches (#412-#422): each is independently parallelizable** (different subsystems: scheduler handlers, Flowchart/ControlFlow, Agent module, Persistence, Http, Reconciliation/Design-Persistence, Publishing compiler, Mediator/Events, Diagnostics, Elsa.Server, Expressions/Caching/Modularity). Safe to work all of these concurrently in separate worktrees since they don't overlap in files, except the stacking notes above.

**Tier 3 — Cleanup (#423):** lowest priority, safe filler work, no dependencies.

## Parallelization guidance
Each Tier 1 issue not called out in the dependency notes above touches a single file/class and can be assigned its own branch/worktree with no collision risk. Tier 2 batches are scoped to non-overlapping subsystem directories and can all run in parallel with each other and with Tier 1 work in different subsystems.

Start by reading the linked issues #374-#423 and the sequencing and dependency notes in this tracking issue. There is no single file, test, or entry point named here; done means coordinating or updating the listed audit work and its tracking surface rather than making one self-contained change.

Written by the indexing model from the issue text.