Repository navigation
aggregator(feed): a goal lined-up task's blockedBy is never gate-checked — a string or [null] blockedBy passes isGoalMeasurement and todayFromSection throws #4316
Description
Finding
The #2417 fix (merged today in PR #4176, main c611bf4) deepened the orchestration section gate for the section's top-level arrays: dependencies elements must now pass isDependencyElement (string task, status in the DependencyRef union, string-typed optional fields), and tier/action elements gained field checks. Inside goals, however, isGoalMeasurement checks linedUp/stalled elements only with isRecord — and a lined-up task's blockedBy field, declared as the very same DependencyRef[] shape, is not checked at all. todayFromSection's blockedText helper calls .map on it, so a gate-passing goal whose lined-up task carries a malformed blockedBy crashes the today view instead of the section being diagnosed invalid and falling back to the derived view.
Scope boundary with #3897 (open): that issue's acceptance criteria enumerate the linedUp element checks as title/horizon/status/horizonWhy and the goal-level fields — blockedBy is not named in it, and a fix implementing those criteria verbatim leaves both crashes below alive. This issue covers only the blockedBy field; everything else in the goal gate stays #3897's.
Evidence (main c611bf4, verified this run)
pm-stack/aggregator/src/model.ts:615-623—LinedUpTask.blockedBy?: DependencyRef[];DependencyRefis the shapeisDependencyElementvalidates for top-leveldependencies.pm-stack/aggregator/src/feed.ts—isGoalMeasurement(:197-212, after aggregator(orchestration): section gate never checks tier/goal array elements — a [null] tier item or goal task passes validation and crashes buildAttention/todayFromSection #2417)::241) shows the house rule for the identical shape one array over.g.linedUp.every(isRecord)andg.stalled.every(isRecord)are the only element checks; no clause touchesblockedBy.isDependencyElement(pm-stack/aggregator/src/derive.ts:688-690—blockedTextdoesdeps?.length ? deps.map(...) : undefined;:698and:714call it ontask.blockedByunguarded. A string has a truthy.lengthbut no.map; a[null]element reachesd.taskon null.- Laptop probe (
~/git/fleet/probe-2026-11-02-laneA-goalblockedby/, verbatimsrc/from main c611bf4 — feed.ts md5 fcfbd045, derive.ts md5 dcdefb5e, both matched to the sandbox clone), importing the realisOrchestrationSection/orchestrationSectionProblemandtodayFromSection:- Control (
blockedBy: [{task, status}]): gatetrue, today rendersblocked by dep-1 (in-progress). blockedBy: "waiting on dep-1"(string): gatetrue, problemnull→todayFromSectionthrowsTypeError: deps.map is not a function.blockedBy: [null]: gatetrue, problemnull→ throwsTypeError: null is not an object (evaluating 'd.task').blockedBy: [{}]: gatetrue→ renders the falsified textblocked by undefined (undefined).
- Control (
Why it matters
The orchestration section is machine-published JSON read fail-soft by design: a malformed section is supposed to be diagnosed (goals (per-goal shape)) and demoted to the derived view. #2417 closed that hole for the section's top-level dependencies array; the identical field nested one level deeper in goals still turns one drifted publisher line into an uncaught TypeError on the today path — or, for [{}], silently falsified blocker text presented as measured state.
Acceptance criteria
isGoalMeasurement(or a helper it uses) validates each lined-up task'sblockedBywhen present: an array whose every element passes the same DependencyRef rule the gate applies to top-leveldependencies(reuseisDependencyElementrather than duplicating the rule).- A section failing only on
blockedByis diagnosed through the existing machinery:orchestrationSectionProblemreportsgoals (per-goal shape), the section falls back to the derived view, andtodayFromSectioncan no longer be reached with ablockedByit throws on. - Regression tests beside the aggregator(orchestration): section gate never checks tier/goal array elements — a [null] tier item or goal task passes validation and crashes buildAttention/todayFromSection #2417 orchestration gate tests cover at least:
blockedByas a string,blockedBy: [null],blockedBy: [{}]— all rejected — plus the well-formedblockedBycontrol still passing and rendering. - Existing aggregator tests stay green.
Dedup: #3897 (open) covers the goal gate's element/field checks but its enumerated criteria omit blockedBy (see scope boundary above); #2417 (closed, fix merged c611bf4) covered top-level dependencies, tiers, actions, and record-ness of goal elements. No open or closed issue names blockedBy in a goal (title search: no hits).
Filed by new-issue-creator-code-a (Lane A) from a verified laptop probe; filed only, not self-solved — the gate-criteria coordination with #3897 is a triage call.
Activity
dezren39 commentedon Nov 2, 2026
agent-note:v1
state: filed
Found via: filed this run (new-issue-creator-code-a, Lane A) — residual of the #2417 gate deepening merged today (c611bf4): top-level
dependenciesgainedisDependencyElement, but a goal lined-up task'sblockedBy(sameDependencyRef[]shape) has no gate clause, andtodayFromSection'sblockedTextcalls.mapon it. Verified on the laptop with verbatim sources at c611bf4 (feed.ts md5 fcfbd045, derive.ts md5 dcdefb5e): string and [null]blockedBypass the gate and throw TypeError; [{}] renders "undefined (undefined)". Probe: ~/git/fleet/probe-2026-11-02-laneA-goalblockedby/. Scope isblockedByonly — the rest of the goal gate remains #3897's. Filed only; enqueued for triage.dezren39 commentedon Nov 2, 2026
🤖 Agent note · picked up
153 remaining items
dezren39 commentedon Nov 4, 2026
agent-note:v1 — agent=repo-worker-code state=picked-up task=6396 lane=8ac61616-3815-4e7b-b33d-840a3829154a at=2026-11-04T17:43:43Z
Claimed this queue task and checkpointed before work. Fresh metadata-only revalidation found issue #4316 open and its exact fix already owned by Drew-authored PR #4581; no PR, branch, or worktree was inspected or changed.
dezren39 commentedon Nov 4, 2026
agent-note:v1 — agent=repo-worker-code state=parked task=6396 lane=8ac61616-3815-4e7b-b33d-840a3829154a at=2026-11-04T17:45:53Z resume=PR-4581-merged-closed-or-ownership-changes
Parked for 30 minutes because PR #4581 remains OPEN, authored by Drew/dezren39, and covers this exact fix at queue/6396-4316-gate-blockedby@fafdebb6c2afe112f21531d5c1ff875605ec6a2a. Do not edit, inspect, merge, or duplicate it. Revalidate #4316/#4581 when resuming.
dezren39 commentedon Nov 5, 2026
agent-note:v1 — agent=repo-worker-code state=picked-up task=6396 lane=8ac61616-3815-4e7b-b33d-840a3829154a at=2026-11-05T01:42:52Z
Claimed and checkpointed with origin=openchamber-scheduled-lane. Fresh metadata-only revalidation: issue #4316 is OPEN; exact-fix PR #4581 is OPEN, Drew/dezren39-authored on queue/6396-4316-gate-blockedby at fafdebb. I did not inspect or touch the PR contents, branch, or worktree. Active ownership conflict; next action is park for 30 minutes and resume only after #4581 merges/closes or ownership changes.
dezren39 commentedon Nov 5, 2026
agent-note:v1 — agent=repo-worker-code state=parked task=6396 lane=8ac61616-3815-4e7b-b33d-840a3829154a at=2026-11-05T01:42:52Z resume=PR-4581-merged-closed-or-ownership-changes
Queue task 6396 parked for 30 minutes after fresh metadata-only verification confirmed issue #4316 OPEN and exact-fix PR #4581 OPEN/Drew-authored on queue/6396-4316-gate-blockedby at fafdebb. No PR contents, branch, or worktree were inspected or changed; no duplicate work was created. Issue labels already reflect parked state (queue/parked, status/parked); work/assigned retained. Revalidate issue, PR state/head/ownership before resuming.
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off