Activity

1. dezren39

   added

   status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

   area/infraInfrastructure, deployment, and operationsInfrastructure, deployment, and operations

   effort/sSmall: expected under 2 hours of workSmall: expected under 2 hours of work

   meta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedIntake review done: acceptance criteria, links, and normalized labels added

   on Oct 27, 2026
2. developing-today commented on Oct 27, 2026

   

   developing-todayBot

   on Oct 27, 2026 – with developing.today

   Contributor

   More actions

   CODE-237
3. dezren39

   added

   mode/hybridOnline work plus a physical step (power, cabling, KVM access to a real device)Online work plus a physical step (power, cabling, KVM access to a real device)

   on Oct 27, 2026
4. dezren39

   added a parent issue on Oct 27, 2026

   • epic(cluster): hardware inventory & first-node selection #1080
5. github-actions

   assigned

   dezren39

   on Oct 27, 2026
6. dezren39

   added

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   and removed

   status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

   on Oct 29, 2026
7. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   🤖 Agent note · escalated

   • Agent: queue worker (repo-worker-code), lane B shift
   • Session / ID: queue task 2366 (triage)
   • Found via: queue claim
   • Task: Triage of task(cluster): verify NIC and switch-gear facts #1097 — verify NIC and switch-gear facts for the core machines (epic epic(cluster): hardware inventory & first-node selection #1080).
   • Expectation: escalated to Drew — the switch half is documented; the NIC half needs the machines themselves.

   Triage findings (checked at current main, laptop clone origin/main):

   • Switch gear IS recorded: doc/inventory/routing-and-switching.md (last updated 2026-04-02) documents the core fabric — Celestica DX010 (×4, one missing fans/PSU), 32× QSFP28 100 GbE per switch, SONiC — plus Mellanox SX6036 and Arista 7050QX in the enrichment checklist. So the inventory's switch side exists.
   • The NIC question is genuinely open: git grep across doc/inventory/ and planning/roadmaps/basement-cluster.md finds no NIC model, no host link-speed record for the core machines — nothing answering "at least 200 Gb ports" one way or the other.
   • One gap already visible from the docs alone: the fabric switches top out at 100 GbE per QSFP28 port, so a ≥200 Gb host attachment would require 2×100G LAG/breakout per machine — worth confirming explicitly when the NICs are read, since the LINSTOR/DRBD design in epics 4–5 depends on the real number.

   Why escalated, not routed to a code packet: answering needs lspci/ethtool output (or a physical read) from the core machines in the basement. A queue worker has no verified hostnames/access for those machines, and guessing at hardware facts is exactly what this issue exists to prevent.

   Ask of Drew: paste per-machine lspci | grep -i eth + ethtool <iface> | grep Speed output (or the NIC model from a physical read) on this issue — with that evidence, an agent can record it in doc/inventory/routing-and-switching.md and file any gap issue via a scoped follow-up packet in one pass. Blocking queue task 2366 as escalated-to-user; issue labelled user/escalated.
8. dezren39

   added

   user/escalatedQueue or user escalation stateQueue or user escalation state

   queue/blockedQueue or user escalation stateQueue or user escalation state

   status/blockedQueue or user escalation stateQueue or user escalation state

   and removed

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   user/escalatedQueue or user escalation stateQueue or user escalation state

   on Oct 29, 2026
9. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   BOARD CLEARING (2026-10-29): Drew confirmed on 2026-10-29 that the on-site basement hardware session is HIS task — ownership claimed, no decision outstanding for the fleet. Removed from the needs-Drew board (user/escalated dropped). The issue stays open and blocked on the physical session itself; dependents stay parked behind it.
10. dezren39

    added

    queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

    source/creatorFiled by the new-issue-creator jobFiled by the new-issue-creator job

    task/triageQueue packet kind: verify, reproduce, and route this itemQueue packet kind: verify, reproduce, and route this item

    on Nov 3, 2026
11. developing-today commented on Nov 3, 2026

    

    developing-todayBot

    on Nov 3, 2026 – with developing.today

    Contributor

    More actions

    agent-note:v1
    state: reviewed (coverage loop-back)
    Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 2366 (triage, blocked, priority 30) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
    Found via: coverage loop-back 2026-11-03