fix(work-items): the seam returns no item body — correct every surface that claimed it did - #3038
Conversation
…e that claimed it did Closes #3028 ship/SKILL.md annotated its get-item call with "# body = the spec", under a heading reading "no inline provider commands". Both halves were wrong: the normalized item object is schema_version, id, title, state, assignees, labels, type, blocked_by_count, parent_id, url — there is no body field, and --body exists only as a write parameter on create-item. A session following the skill's own snippet to read the container spec got no spec text, and the placement implied the seam could do something it cannot. Fixed at the source rather than only at the reported call site. The routing table in reference/tracker-seam.md listed "single-item fetch" under Coordination with nothing said about the body, which is what let the assumption spread — the same false premise was independently proposed in Lane D's first-draft design (#2937) and caught by the same audit. The table now marks single-item fetch as identity/state/parent_id NOT body, lists reading an item's body under Provider mechanics, and states the split outright: get-item stays authoritative for parent_id (how a slice reaches its container), body text is a provider-mechanic read, and a surface showing one must label it as such. Degradation is named, not implied: provider mechanics run unbound so the read survives a missing binding, and local-markdown stores item text as the file itself rather than having a body concept. Call sites corrected: ship (the reported one), work's pass-by-reference step (same premise, "fetch the container via the seam ... and read its Brief body" — not in the issue's list), and decompose's "fetch full body and comments", which left the mechanism to inference. planning:plan was checked and carries no such assumption. ship's eval no longer asserts the container is read wholly through seam verbs. Repo-wide grep for get-item near body/spec/brief now returns only these corrections. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CnzwTKoTa6xNY7iyEzMYpm
|
Claude finished @kyle-sexton's task in 43s —— View job Security review — no issues found
Skip gate: triggered. This PR has no security-relevant surface. All seven changed files are
No code paths, scripts, GitHub Actions workflows, permissions, or dependency pins are touched. The No findings to report. |
|
Last security-reviewed head: |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 385b80c942
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…ter's paginated recipe PR review (Codex P2). The provider-mechanic read I added folded comments into gh issue view --json body,title,comments. That command takes no pagination flag, and the GitHub adapter has a dedicated "List item comments" recipe using gh api --paginate precisely because the endpoint returns 30 per page and reports nothing when it truncates — the adapter's own words: an unpaginated read silently drops the newest comments, and this repo already has items past that count. The failure is worse here than generic truncation: this step promises "full body and comments" and feeds decomposition, so silently missing the newest comments means drafting slices against superseded requirements — exactly the stale-projection failure the re-decompose flow exists to correct. Now stated as two separate reads, with the comments one routed to the adapter's recipe by name rather than restated inline (a copied command is a second SSOT that drifts from the recipe it copies). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CnzwTKoTa6xNY7iyEzMYpm
|
Claude finished @kyle-sexton's task in 49s —— View job Security review — no issues found
Skip gate: triggered. Last security-reviewed head was
This is a prose-only correction to skill documentation — no code, scripts, GitHub Actions workflow, permissions, or dependency pins are touched, and the No findings to report. |
|
Claude finished @kyle-sexton's task in 29s —— View job Code review — skipped
Skip gate triggered: this PR is merged (closed), and the code-review lane's skip gate stops early whenever "PR is closed or not open." No review was performed and no findings are posted, per the skill's instructions ( If a fresh review is wanted, it would need to run against an open PR or branch. |
|
Claude has reviewed this PR 1 time. The lane skips further automatic reviews after 5; deleting this comment resets the count. |
2 participants
Closes #3028
Summary
ship's macro-state snippet annotated itsget-itemcall with# body = the spec, under a headingreading "Through the seam (coordination verbs; no inline provider commands)". Both halves were
wrong, and together they were worse than either alone: a session following the skill's own snippet
to read the container spec got no spec text, while the placement asserted the seam could do
something it cannot.
The normalized item object is
schema_version, id, title, state, assignees, labels, type, blocked_by_count, parent_id, url— there is nobodyfield, and--bodyexists only as awrite parameter on
create-item.Fix
Fixed at the source, not only at the reported call site.
reference/tracker-seam.md'soperation-routing table listed "single-item fetch" under Coordination with nothing said about the
body — that omission is what let the assumption spread, and it demonstrably did: the same false
premise was independently proposed in Lane D's first-draft design (#2937) and caught by the same
audit that filed this issue. The table now:
parent_id— not bodyget-itemremains authoritative forparent_id(how a slice reaches its container), body text is a provider-mechanic read
(
gh issue view <n> --repo <owner>/<repo> --json body,titleon GitHub, the provider's RESTequivalent otherwise), and a surface that shows a body read must label it as such
Degradation is named rather than implied: provider mechanics run unbound, so the read survives a
missing binding; and
local-markdownstores item text as the file itself rather than having a bodyconcept, so it is called out instead of papered over as parity.
Call sites corrected:
skills/ship/SKILL.mdskills/work/SKILL.mdskills/decompose/SKILL.mdskills/ship/evals/evals.jsonplanning:planwas checked as the issue asks and carries no such assumption — no change.Verification
grep -rn "get-item"acrossplugins/anddocs/, filtered to hits nearbody/spec/brief, now returns only these corrections — no surface still claims the seam
returns a body
check-skill.shonship,work,decompose→ PASS, 0 errors each. Warning counts areunchanged from baseline (1 / 2 / 2), verified by re-running against the stashed tree — all
pre-existing (
no Gotchas surface, soft line-count targets)ship/evals/evals.jsonvalidated againstplugins/skill-quality/reference/evals.schema.json→ OKcheck-evals-quality.sh→ PASS, 0 warningsmarkdownlint-cli2overplugins/work-items/**→ 0 issues in 46 filescheck-skill-portability.sh/check-shell-portability.shvsorigin/main→ no unexcusedfindings
check-changelog-parity.sh(--check,--check-bump,--check-order),validate-plugins.sh,validate-plugin-contracts.mjs,generate-catalog.mjs,generate-cheatsheet.mjs→ all clean /in sync
Patch bump
0.36.1→0.36.2with the matching CHANGELOG entry, per the issue's acceptancecriteria.
Related
specmode documentsthe same provider-mechanic body read on the
reviewside. This item is the fix at the sourceGenerated by Claude Code