Orchestrator ignores cascading document dependencies — parallelises work that must be sequential

Problem

When working with a set of documents that have cascading dependencies (Document 1 must be finalised before Document 2 can be QC'd, Document 2 before Document 3, etc.), the orchestrator defaults to parallelising the QC/fix loops for all documents simultaneously.

This happens even when:

• The user has previously explained the sequential dependency
• The documents are explicitly numbered (Pillar 1, Pillar 2, Pillar 3, Pillar 4)
• The content of later documents depends on earlier documents being finalised first

Expected behaviour

The orchestrator should recognise cascading document dependencies and process them sequentially: complete the full QC loop (adversarial QC → fix → re-QC → PASS) for Document 1 before starting the QC loop for Document 2, and so on.

Actual behaviour

The orchestrator launches parallel fix agents and plans parallel re-QC loops for all documents, requiring the user to intervene and correct the execution order mid-session.

Impact

• User must re-explain the cascading dependency every session
• Tokens wasted on incorrect parallel execution plans
• Trust erosion: the user sees the orchestrator repeatedly making the same structural mistake despite prior correction

Reproduction

1. Give the orchestrator a set of numbered documents with cascading content dependencies
2. Ask it to run adversarial QC loops on all of them
3. Observe that it parallelises instead of sequencing

Environment

• Claude Code CLI
• Model: Opus 4.6
• Using agent orchestration with background subagents