Repository navigation
research_workflow_items: the ids command reads the package manifest shape-trusted — wrong-shape package.json surfaces as bare Attribute/Key/Type errors naming no file or field, not the tool's fail() diagnostics #6856
Description
research_workflow_items: the ids command reads the package's package.json manifest shape-trusted — wrong shapes surface as bare Attribute/Key/Type errors naming no file or field, not the tool's fail() diagnostics
Summary
scripts/research_workflow_items.py list_ids (the ids command, :952) reads the research package's own package.json manifest with a bare json.loads(...).get("segments", []) (:956-957) and projects [s["id"] for s in segments] (:976) with no shape validation at all. A valid-JSON-but-wrong-shape manifest therefore surfaces through the CLI's catch-all as a bare Python error that names neither the file nor the field — the exact failure mode #6854 filed for scripts/research_workflow.py's profile/state/trigger inputs, in the sibling module #6854 did not cover (its scope was research_workflow.py only; package.json / list_ids / segments appear nowhere in it).
The rest of this tool family validates with fail() diagnostics that name the file and the expectation (e.g. sync_research_workflow.py's load_json_object: "expected a JSON object"; research_workflow.py's field-level fail() checks). This one read is the unguarded remainder.
Verified this run (laptop probe, real CLI end-to-end, @65beb42c1a)
Probe: ~/git/fleet/probe-rw-items (research_workflow.py + research_workflow_items.py + research_workflow_live.py copied verbatim; package created through the real init CLI exactly as scripts/tests/test_research_workflow_items.py does; then ids --package <pkg> against crafted package.json files). Controls behave as designed:
| package.json | Observed |
|---|---|
| absent (control) | rc=0, ids listed, segments: [] |
{"segments":[{"id":"S1"},{"id":"S2"}]} (control) |
rc=0, segments listed |
[{"id":"S1"}] (list top level) |
rc=1, error: 'list' object has no attribute 'get' |
"hello" (string top level) |
rc=1, error: 'str' object has no attribute 'get' |
{"segments":"S1S2"} (segments as string) |
rc=1, error: string indices must be integers, not 'str' |
{"segments":{"id":"S1"}} (segments as object) |
rc=1, error: string indices must be integers, not 'str' (iterates the object's keys) |
{"segments":[{"name":"x"}]} (segment missing id) |
rc=1, error: 'id' |
{"segments":["S1"]} (segment as string) |
rc=1, error: string indices must be integers, not 'str' |
not json |
rc=1, error: Expecting value: line 1 column 1 (char 0) — no filename |
No case names package.json, the segments field, or the expected shape; the non-JSON case doesn't even name the file that failed to parse. (The CLI catches the exceptions, so there is no traceback — the defect is the undiagnosed message, same as #6854.)
Why it matters
idsis the inventory command operators and other workflow steps use to enumerate a package's concepts/items/segments; package.json is a hand-editable, generated-and-edited artifact inside every research package — exactly the kind of file that gets truncated, merged badly, or written by another tool in a slightly different shape.- When that happens, the operator gets
'list' object has no attribute 'get'with no indication that package.json is the malformed input, out of the several JSON files a package contains (state block, profile, transcripts, receipts). The tool family's whole contract is named diagnostics; this read breaks it. - Sibling of research_workflow: profile, state block and trigger fixtures are shape-trusted — non-object JSON and wrong-shape transcript/concepts/dependencies fields surface as bare Attribute/Key/Type errors naming no file or field, not the tool's fail() diagnostics #6854 (research_workflow.py inputs) and the Design: parsed is not validated — one shape contract at every JSON trust boundary #3068 parsed-is-not-validated pattern; the fix idiom already exists in the family (
fail()/load_json_object).
Acceptance criteria
-
list_idsvalidates the manifest before use: top level is a JSON object,segments(when present) is a list of objects each with a stringid; any violation — including a non-JSON manifest — fails via the tool'sfail()diagnostic naming package.json and the field/expectation, never a bare Attribute/Key/Type/JSONDecode message. - Well-formed manifests (including a missing package.json and a manifest without
segments) behave exactly as today. - New tests in scripts/tests/test_research_workflow_items.py cover the probed wrong shapes (list/string top level, segments as string/object, segment missing
id, segment as string, non-JSON) asserting the single-lineerror: …contract names package.json, plus the controls (oracle: the family'sfail()diagnostic style, as in research_workflow: profile, state block and trigger fixtures are shape-trusted — non-object JSON and wrong-shape transcript/concepts/dependencies fields surface as bare Attribute/Key/Type errors naming no file or field, not the tool's fail() diagnostics #6854).
Activity
developing-today commentedon Nov 7, 2026
CODE-2124
dezren39 commentedon Nov 7, 2026
🤖 Agent note · filed
developing-today commentedon Nov 8, 2026
🤖 Agent note · picked up
17 remaining items
developing-today commentedon Nov 8, 2026
🤖 Agent note · parked
dezren39 commentedon Nov 8, 2026
🤖 Agent note · parked (CI pending)
dezren39 commentedon Nov 8, 2026
Picked up by
repo-worker-code-h— working this now. (Fleet queue fallback mode: the queue backend is down, so this issue's comments carry the claim. The claim stays live whilerepo-worker-code-hposts progress markers; after 30 minutes of silence any other worker may pick this up.)dezren39 commentedon Nov 8, 2026
Progress from
repo-worker-code-h: MID-SHIFT FALLBACK: backend failed at checkpoint (task 11083 not-claimed verdict after claimed checkpoint succeeded); tests passed 17/17 on laptop, merging PR 7007 nextMerge pull request #7007 from developing-today/queue/11083-6856-manif…
dezren39 commentedon Nov 8, 2026
🤖 Agent note · done
dezren39 commentedon Nov 8, 2026
Released by
repo-worker-code-h(outcome: done). task 11083 fixed_merged: PR #7007 merged 5e3ad18, issue #6856 closed; tests: unittest scripts.tests.test_research_workflow_items 17 OK on laptop; no Codex findings posted; PR #7007