Paths: File paths (shared/, references/, ../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.

Concurrency Auditor (L3 Worker)

Specialized worker auditing concurrency, async patterns, and cross-process resource access.

Purpose & Scope

• Worker in ln-620 coordinator pipeline
• Audit concurrency (Category 11: High Priority)
• 7 checks: async races, thread safety, TOCTOU, deadlocks, blocking I/O, resource contention, cross-process races
• Two-layer detection: grep finds candidates, agent reasons about context
• Calculate compliance score (X/10)

Inputs (from Coordinator)

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

Receives contextStore with: tech_stack, best_practices, codebase_root, output_dir.

Workflow

MANDATORY READ: Load shared/references/two_layer_detection.md for detection methodology.

1. Parse context — extract tech_stack, language, output_dir from contextStore
2. Per check (1-7):
   • Layer 1: Grep/Glob scan to find candidates
   • Layer 2: Read 20-50 lines around each candidate. Apply check-specific critical questions. Classify: confirmed / false positive / needs-context
3. Collect confirmed findings with severity, location, effort, recommendation
4. Calculate score per shared/references/audit_scoring.md
5. Write Report — build in memory, write to {output_dir}/628-concurrency.md (atomic single Write)
6. Return Summary to coordinator

Audit Rules

Unified severity escalation: For ALL checks — if finding affects payment/auth/financial code → escalate to CRITICAL regardless of other factors.

1. Async/Event-Loop Races (CWE-362)

What: Shared state corrupted across await/yield boundaries in single-threaded async code.

Layer 1 — Grep patterns:

Layer 2 — Critical questions:

• Is the variable shared (module/global scope) or local?
• Can two async tasks interleave at this await point?
• Is there a lock/mutex/semaphore guarding the access?

Severity: CRITICAL (payment/auth) | HIGH (user-facing) | MEDIUM (background)

Safe pattern exclusions: Local variables, const declarations, single-use await (no interleaving possible).

Effort: M

2. Thread/Goroutine Safety (CWE-366)

What: Shared mutable state accessed from multiple threads/goroutines without synchronization.

Layer 1 — Grep patterns:

Layer 2 — Critical questions:

• Is this struct/object actually shared between threads? (single-threaded code → FP)
• Is mutex/lock in embedded struct or imported module? (grep may miss it)
• Is go func capturing by value (safe) or by reference (unsafe)?

Severity: CRITICAL (payment/auth) | HIGH (data corruption possible) | MEDIUM (internal)

Safe pattern exclusions: Go map in init() or main() before goroutines start. Rust Arc<Mutex<T>> (already safe). Java Collections.synchronizedMap().

Effort: M

3. TOCTOU — Time-of-Check Time-of-Use (CWE-367)

What: Resource state checked, then used, but state can change between check and use.

Layer 1 — Grep patterns:

Layer 2 — Critical questions:

• Is the check used for control flow (vulnerable) or just logging (safe)?
• Is there a lock/retry around the check-then-use sequence?
• Is the file in a temp directory controlled by the application (lower risk)?
• Could an attacker substitute the file (symlink attack)?

Severity: CRITICAL (security-sensitive: permissions, auth tokens, configs) | HIGH (user-facing file ops) | MEDIUM (internal/background)

Safe pattern exclusions: Check inside try/catch with retry. Check for logging/metrics only. Check + use wrapped in file lock.

Effort: S-M (replace check-then-use with direct use + error handling)

4. Deadlock Potential (CWE-833)

What: Lock acquisition in inconsistent order, or lock held during blocking operation.

Layer 1 — Grep patterns:

Layer 2 — Critical questions:

• Are these the same lock (reentrant = OK) or different locks (deadlock risk)?
• Is the lock ordering consistent across all call sites?
• Does the external call inside lock have a timeout?

Severity: CRITICAL (payment/auth) | HIGH (app freeze risk)

Safe pattern exclusions: Reentrant locks (same lock acquired twice). Locks with explicit timeout (asyncio.wait_for, tryLock).

Effort: L (lock ordering redesign)

5. Blocking I/O in Async Context (CWE-400)

What: Synchronous blocking calls inside async functions or event loop handlers.

Layer 1 — Grep patterns:

Layer 2 — Critical questions:

• Is this in a hot path (API handler) or cold path (startup script)?
• Is the blocking duration significant (>100ms)?
• Is there a legitimate reason (e.g., sync read of small config at startup)?

Severity: HIGH (blocks event loop/async context) | MEDIUM (minor blocking <100ms)

Safe pattern exclusions: Blocking call in if __name__ == "__main__" (startup). readFileSync in config loading at init time. Sync crypto for small inputs.

Effort: S-M (replace with async alternative)

6. Resource Contention (CWE-362)

What: Multiple concurrent accessors compete for same resource without coordination.

Layer 1 — Grep patterns:

Layer 2 — Critical questions:

• Are multiple writers actually concurrent? (Sequential = safe)
• Is there OS-level atomicity guarantee? (e.g., O_APPEND for small writes)
• Is ordering important for correctness?

Severity: HIGH (data corruption) | MEDIUM (ordering issues)

Safe pattern exclusions: Single writer pattern. OS-guaranteed atomic operations (small pipe writes, O_APPEND). Message queues with ordering guarantees.

Effort: M

7. Cross-Process & Invisible Side Effects (CWE-362, CWE-421)

What: Multiple processes or process+OS accessing same exclusive resource, including operations with non-obvious side effects on shared OS resources.

Layer 1 — Grep entry points:

Layer 2 — This check relies on reasoning more than any other:

1. Build Resource Inventory:

   Resource	Exclusive?	Accessor 1	Accessor 2	Sync present?

2. Trace Timeline:

   t=0ms  operation_A() -> resource_X accessed
   t=?ms  side_effect   -> resource_X accessed by external process
   t=?ms  operation_B() -> resource_X accessed again -> CONFLICT?
   

3. Critical Questions:

   • Can another process (terminal, OS, child) access this resource simultaneously?
   • Does this operation have invisible side effects on shared OS resources?
   • What happens if the external process is slower/faster than expected?
   • What happens if user triggers this action twice rapidly?

Severity: CRITICAL (two accessors to exclusive OS resource without sync) | HIGH (subprocess + shared file without lock) | HIGH (invisible side effect detected via reasoning)

Safe pattern exclusions: Single accessor. Retry/backoff pattern present. Operations sequenced with explicit delay/await.

Effort: M-L (may require removing redundant access path)

Scoring Algorithm

MANDATORY READ: Load shared/references/audit_worker_core_contract.md and shared/references/audit_scoring.md.

Output Format

MANDATORY READ: Load shared/references/audit_worker_core_contract.md and shared/templates/audit_worker_report_template.md.

Write report to {output_dir}/628-concurrency.md with category: "Concurrency" and checks: async_races, thread_safety, toctou, deadlock_potential, blocking_io, resource_contention, cross_process_races.

Return summary to coordinator:

Report written: docs/project/.audit/ln-620/{YYYY-MM-DD}/628-concurrency.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

Critical Rules

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

• Do not auto-fix: Report only — concurrency fixes require careful human review
• Two-layer detection: Always apply Layer 2 reasoning after Layer 1 grep. Never report raw grep matches without context analysis
• Language-aware detection: Use language-specific patterns per check
• Unified CRITICAL escalation: Any finding in payment/auth/financial code = CRITICAL
• Effort realism: S = <1h, M = 1-4h, L = >4h
• Exclusions: Skip test files, skip single-threaded CLI tools, skip generated code

Definition of Done

MANDATORY READ: Load shared/references/audit_worker_core_contract.md.

• contextStore parsed (language, concurrency model, output_dir)
• All 7 checks completed with two-layer detection:
  • async races, thread safety, TOCTOU, deadlock potential, blocking I/O, resource contention, cross-process races
• Layer 2 reasoning applied to each candidate (confirmed / FP / needs-context)
• Findings collected with severity, location, effort, recommendation
• Score calculated per shared/references/audit_scoring.md
• Report written to {output_dir}/628-concurrency.md (atomic single Write call)
• Summary returned to coordinator

Reference Files

• Two-layer detection methodology: shared/references/two_layer_detection.md
• Audit output schema: shared/references/audit_output_schema.md

Version: 4.0.0 Last Updated: 2026-03-04