Fable 5 orchestration: high token spend with poor written-spec adherence (user-reported)

What happened

Long orchestration session (Claude Code, Fable 5) piloting a multi-lot delivery plan from a written spec file, with subagent teams. The user reports, and the transcript confirms, a recurring failure pattern: high token consumption with incomplete delivery of the explicitly written requirements. The user summarized it as "you consume my tokens but don't do the requested work".

Concrete, factual gaps (all were explicit written requirements in the spec file the session was piloting):

1. The spec required an adversarial review before EVERY merge. Four lots were merged with only the orchestrator's own verification, no independent review.
2. The spec's issue tracker was designated as the single source of truth so the user would not have to repeat himself. The tracker was never updated during the session (no status, no progress notes) until the user complained; everything stayed in the chat.
3. The spec explicitly stated that macOS packaging must be produced even while a signing certificate decision is pending. The assistant instead disabled the macOS package based on a stale memory note, re-introducing a gap the spec had preemptively closed.
4. Highly visible deliverables (the UI selector that was the stated top priority of the plan) were left unstarted while lower-visibility plumbing was completed, so the user saw little value for the tokens spent.
5. A runtime bug the user reported as fixed-and-shipped was still reproducible on his machine, partly because a second bug (updater does not restart processes) masked delivery; the session declared the fix "published" without runtime confirmation on the user's machine.

Why this matters

Each individual step looked productive (merges, green pipelines, reviews on some lots), but the session drifted from the user's written contract. The user had to intervene three separate times to re-state requirements that were already written down in the file the session was explicitly asked to follow. That is the core failure: written-spec adherence and deliverable-visibility prioritization, not raw capability.

Expected behavior

• Treat an explicit written spec as a checklist and reconcile against it continuously, not from memory.
• Prioritize user-visible deliverables when the spec marks them as the top priority.
• Keep the designated tracking system (issues) updated as the single source of truth.
• Never claim "delivered/fixed" without runtime confirmation when the spec defines delivery as runtime-verified.

Reported at the user's explicit request.