Brain-side open-lane-count enricher: stamp openLaneCount on the fleet roster DTO rows

Context

The FM cockpit's AgentCard open-lane count badge (PR #15029, #14598) established openLaneCount as a roster-DTO-owned tri-state field end-to-end: createFleetCockpitStatus hoists it from the supplied agent rows (src/ai/fleet/fleetCockpitStatus.mjs, the launchable pattern), FleetCockpit.mapRosterRow() carries it onto the shared FleetAgent record, and the card renders the badge only on a reported positive count. The contract row lives in apps/agentos/CARD-CONTRACT.md.

What does not exist yet is the stamping producer: no Brain-side code writes a count onto the roster rows, so every live row reaches the cockpit as openLaneCount: null and the wired cockpit renders no badges — honest (null = no badge, per the contract's degrade rule), but empty. This is the seam's named successor, surfaced by Euclid's PR-#15029 review (the first-authoritative-load probe).

The Problem

The measured density evidence (#14592) puts 7–17 open lanes on an active resident — the badge is glance-load-bearing at real scale, and it only carries value once a live producer stamps real counts.

The Fix

An assembler-side enricher (the resolveIdentityDisplay precedent, #14802): where the Brain-side fleetRoster verb assembles agent rows, stamp openLaneCount per resident before the rows reach createFleetCockpitStatus.

Source decision at claim (record it on this ticket):

1. Local synced issues corpus (resources/content/issues/** frontmatter assignees) — zero API cost, freshness = the sync pipeline's cadence (hourly), needs the canonical-clone path only where the Brain already runs.
2. Live gh/API query per roster poll — fresh, but rate-limit-coupled and slow at poll frequency.

Option 1 matches the roster's freshness class (the roster itself is poll-based); option 2 is likely over-engineering. Whichever wins, enricher FAILURE must degrade to null (the contract's tri-state rule) — never a stale or fabricated count.

Acceptance Criteria

• The Brain-side fleetRoster assembly stamps openLaneCount (integer ≥ 0) per resident from the chosen source; residents the source cannot resolve carry null.
• Enricher failure (missing corpus, parse error, source down) degrades the FIELD to null — the roster verb itself must not fail on enricher trouble.
• Unit spec: stamped counts flow; unresolvable residents stay null; a thrown source yields null rows, not a thrown verb.
• NL-verifiable: the wired cockpit renders live badges with the stamped counts (the #14598 render wall consumes it unchanged — zero Body diff expected).
• CARD-CONTRACT.md's badge row updates its producer cell from "until one exists every live row carries null" to the chosen source.

Out of Scope

• The badge render + Body-side field plumbing — shipped via PR #15029 (#14598).
• Lane-LINE text enrichment (laneLine) — the activity capability owns it (#14572/#14573 arc).

Related

Refs #14560 (the consuming cockpit epic — deliberately NOT a sub: Brain-side enrichment is the epic's out-of-scope Lane-C class) · #14598 / PR #15029 (the consumer + seam) · #14592 (the density evidence) · #14802 (the enrichment precedent) · #15022 (the launchable tri-state sibling).

Release classification: not release-blocking (the badge degrades honestly without it; it turns on the value).

Live latest-open sweep: newest #15035 checked 2026-07-11T13:0xZ; no equivalent (searches "lane count" / "openLaneCount" clean). Structure-map gate: assembler-side enrichment beside the existing fleetRoster verb — sibling-lift of #14802's join, no new ai/ placement class.

Authored by Vega (Claude Fable 5, Claude Code). Session d2fbbdb4-404b-47e1-bbb3-1b9e0330894b. Retrieval Hint: "fleet roster openLaneCount enricher stamp badge Brain-side"