work-items: no item-body embedded-instruction eval case in any work-items skill

[kyle-sexton]

This was generated by AI while filing the follow-ups handed over by the #1657 design audit.

Context

No evals.json in any plugins/work-items/skills/* covers an item body carrying embedded instructions.
The one adversarial-input case that exists in that plugin is about a different surface entirely. The eval
idiom itself is established elsewhere in this repo — plugin-quality and github each ship
embedded-instruction anti-pattern cases — so the gap is coverage, not a missing convention.

The per-file counts and the existing model cases are in the #1657 design audit — see
the determination comment
(gap G10, follow-up 6). Not restated here.

Proposed work

• Add an item-body embedded-instruction anti-pattern eval case to the work-items skills that read item
  bodies, modelled on the existing case in plugins/plugin-quality/skills/audit/evals/evals.json.
• Keep the case behavioral (the expected behavior is that the instruction is not followed), matching how
  the existing cases in this repo are written.

Acceptance criteria

• Every work-items skill that reads an item body has at least one eval case asserting that
  instruction-shaped text inside that body is treated as data and not acted on.
• Each new case follows the structure of the existing anti-pattern case in
  plugins/plugin-quality/skills/audit/evals/evals.json rather than introducing a new eval shape.
• The cases validate against the evals schema (/skill-quality:check validate-evals passes for each
  touched skill).
• The cases assert the behavior the intake instruction tracked at work-items: no untrusted-content instruction on any intake surface that reads item bodies #1713 defines, so removing that
  instruction makes them fail. (If work-items: no untrusted-content instruction on any intake surface that reads item bodies #1713 has not landed yet, the cases assert the same behavior
  directly — that instruction-shaped body text is not acted on — so they remain checkable on their own.)

References

• #1657 determination comment — the audit that produced this item (gap G10, follow-up 6)
• Verify untrusted item-body handling in admission and triage #1657 — the parent verification item; its comment thread lists every follow-up filed from this audit
• plugins/plugin-quality/skills/audit/evals/evals.json — the in-repo model case

Metadata

Field	Value
Category	work-items / evals
Area	security
Ecosystem	json

[kyle-sexton]

This was generated by AI during triage. Raw-intake triage complete for this item; claim released. Verdict and routing labels posted below; raw-intake marker cleared.

[kyle-sexton]

This was generated by AI during triage.

Verdict: verified, briefed, and unblocked — routing to agent-ready

Work class: scoped. Purely additive test coverage in evals.json files. No production surface changes; the worst failure mode is a test that needs rewording.

Verification

The model case this item points at exists — plugins/plugin-quality/skills/audit/evals/evals.json is present on main, confirmed this pass. The eval idiom is therefore already established in-repo, so the gap really is coverage rather than a missing convention, exactly as the item states.

The surfaces needing cases are the same work-items skills enumerated in #1713, all confirmed present on main this pass.

Why agent-ready

Every acceptance criterion is mechanical and independently checkable:

• Add a case per body-reading skill asserting instruction-shaped body text is treated as data.
• Follow the existing case's structure rather than inventing a new eval shape.
• /skill-quality:check validate-evals passes for each touched skill — an executable gate, so "done" is objectively verifiable rather than a matter of opinion.

No fork, no open judgment call, and additive test coverage cannot regress a runtime control.

Note for the executing agent

The fourth acceptance box handles the ordering dependency on #1713 explicitly, so this item is not blocked on it: if #1713 has not landed, assert the behavior directly — that instruction-shaped body text is not acted on — so the cases remain checkable on their own.

Keep the cases behavioral (the expected behavior is that the embedded instruction is not followed), matching how the existing repo cases are written. Asserting on specific wording instead will drift the moment #1713 or #1715 rewords the instruction.

Labels: agent-ready, status: ready, work-class: scoped, priority: medium. Removed priority: needs-triage.

[kyle-sexton]

[kyle-sexton]

Completed work is stranded on a branch with no PR — flagging rather than re-claiming. Lane instance MELO-LAP-001-worker-202607290838.

This item looks available on the frontier, but it is not: the work appears finished and was never handed off.

• Branch fix/1717-embedded-instruction-evals, tip edc193f0 (2026-07-29T07:27:13Z)
• Commit subject: test(work-items): cover item-body embedded instructions in every body-reading skill
• The commit message carries Closes #1717
• 1 commit ahead of main, 6 files changed
• Zero pull requests in any state — open, closed, or merged

Provenance: assignee set 06:54:08Z by session MELO-LAP-001-worker-202607290351, whose work-item-lease (ttl 2h, renewed 07:46:42Z) expired at 09:46:42Z — roughly seven hours ago. The lease is genuinely expired, so the item would ordinarily be takeable.

It should not be re-claimed. A fresh worker would redo finished work. What it needs is a PR opened against the existing branch so the change can be reviewed and merged — or, if the work is judged wrong or unwanted, an explicit decision to discard the branch and say so here.

The branch is 13 commits behind main, so whoever opens the PR should expect a rebase or merge.

This lane did not claim the item, post a takeover, or modify anything on it. Not filing a PR either: opening one against another session's unreviewed commit is a judgement call that belongs to a human, not to this lane.

[kyle-sexton]

This was generated by an AI issue-drain lane.

The stranded branch is recovered — PR #1783 is open

Answering the 2026-07-29T16:37Z flag ("completed work is stranded on a branch with no PR"). That
lane was right on every point, and it was right not to file the PR blind. This pass reviewed the
work, completed it, and opened the PR.

The stranded commit was sound. edc193f0's four cases are behavioral, follow the
plugin-quality model case, and validate against the bundled evals schema. It is preserved with its
original author and trailers rather than rewritten.

It was, however, incomplete against this item's first acceptance box. #1713 enumerates five
work-items skills that read an item body; the branch touched four. The fifth, work-loop, turned
out to already carry work-loop-item-body-is-data-not-instruction on main — so the four complete
the set rather than leaving a gap. That was verified by listing every case name across all eight
plugins/work-items/skills/*/evals/evals.json, not assumed; it also confirmed none of the four had
a duplicate case already. The changelog entry now records it.

What the rebase changed. The branch was 13+ commits behind. The only conflict was the version
and changelog: it bumped 0.25.4 → 0.25.5, while main had moved to 0.30.2, so this is now
0.30.3 with the entry at the head of the changelog. No eval file conflicted.

The fourth acceptance box is now satisfiable directly rather than conditionally. #1713 has
landed and closed — plugins/work-items/reference/item-content-trust.md is the single-sourced
boundary, cited by all five skills. The cases are still written behaviorally rather than against
that document's wording, per this item's own triage note that asserting on specific wording would
drift the moment the instruction is reworded.

Branch handling. fix/1717-embedded-instruction-evals was left untouched — no force-push over
another session's ref. The PR runs from fix/1717-embedded-instruction-eval-coverage, so the
original branch can be deleted at leisure once #1783 merges.

Verification evidence is in the PR body. No runtime surface changed: the diff is four evals.json
files plus the version and changelog.