⚠️This is a deliberately incomplete card, filed to preserve a lead rather than lose it. It is not a defect report.
What is known
The dev on #8006 measured an out-of-scope defect it described as a rowToItem driver-path bug while investigating put() round-tripping in packages/metadata-core / packages/metadata-fs. Its final session state was:
ready to file out-of-scope issue #8006-adjacent
needs_action: provide GitHub issue number for rowToItem driver-path bug, or run 'gh auth login'
It could not file it: cloud dev containers get 403 on every GitHub API call, so the issue text lived only in the session.
What is lost, and why — my error
I archived that container before recovering the text. My own patrol instruction said to archive #8006's session if it was idle, on the reasoning that the card carries the blocking question so the container is not load-bearing. That reasoning was correct for #8006's ruling and wrong for this finding, which existed nowhere else.
⇒ Lesson, recorded on seat sticker #6367: read needs_action, not just status_category, before archiving. An IDLE container can still be the only copy of something. review_ready and need_input describe whether the dev stopped — not whether it is holding work that exists nowhere else.
This is the same class as the two archived sessions I flagged from other seats earlier today (#7820, #7641 — both released while holding unanswered questions). I named that failure mode and then committed it.
What a picker-up should do
⛔ Do not treat "a rowToItem driver-path bug exists" as established. It is one sentence from a session summary, with no measurement, no file, no reproduction, and no severity behind it.
Re-derive it from scratch: rowToItem on the driver path, in the neighbourhood a put() / get() round-trip exercises. If nothing is wrong there, close this card as not reproducible — that is a perfectly good outcome and better than carrying a phantom.
⚠️ Pair any zero-hit with a positive control that exists now.
Recovery option, if the lead proves worth it
The archived session is session_01R2bDVNYU7EytuX1AbtEUe7. unarchive_session would make its transcript readable again and the text is presumably still in it. I did not spend that recovery cost under an active rate-limit constraint — but it is available, and it is cheaper than re-deriving if the lead turns out to matter.
What is known
The dev on #8006 measured an out-of-scope defect it described as a
rowToItemdriver-path bug while investigatingput()round-tripping inpackages/metadata-core/packages/metadata-fs. Its final session state was:It could not file it: cloud dev containers get 403 on every GitHub API call, so the issue text lived only in the session.
What is lost, and why — my error
I archived that container before recovering the text. My own patrol instruction said to archive #8006's session if it was idle, on the reasoning that the card carries the blocking question so the container is not load-bearing. That reasoning was correct for #8006's ruling and wrong for this finding, which existed nowhere else.
⇒ Lesson, recorded on seat sticker #6367: read
needs_action, not juststatus_category, before archiving. AnIDLEcontainer can still be the only copy of something.review_readyandneed_inputdescribe whether the dev stopped — not whether it is holding work that exists nowhere else.This is the same class as the two archived sessions I flagged from other seats earlier today (#7820, #7641 — both released while holding unanswered questions). I named that failure mode and then committed it.
What a picker-up should do
⛔ Do not treat "a
rowToItemdriver-path bug exists" as established. It is one sentence from a session summary, with no measurement, no file, no reproduction, and no severity behind it.Re-derive it from scratch:
rowToItemon the driver path, in the neighbourhood aput()/get()round-trip exercises. If nothing is wrong there, close this card as not reproducible — that is a perfectly good outcome and better than carrying a phantom.Recovery option, if the lead proves worth it
The archived session is
session_01R2bDVNYU7EytuX1AbtEUe7.unarchive_sessionwould make its transcript readable again and the text is presumably still in it. I did not spend that recovery cost under an active rate-limit constraint — but it is available, and it is cheaper than re-deriving if the lead turns out to matter.