Repository navigation
refactor(work-items): resolve the view medium through the shared resolver #12711
Description
Parent
Source: PLAN Phase 9, topic planning-chain-consolidation. Epic: #12646.
Depends on
Outcome
work-items:triage resolve their medium through the shared resolver CLI and print the report line, naming no medium values themselves; their evals match.
Demo: Run work-items:triage on a sample: it prints the report line; the skill text lists no medium values.
The Brief (Problem, Goal, Constraints) is in the epic body.
Decisions
- Q14: medium moves onto ADR 0075 scopes; ~/.claude/rendered-views.md is no longer read.
- Q17: One fallback chain; every view lane names the medium used and the fact that decided it.
- Q52: AC15 covers every view lane, planning chain first.
Key interfaces
Contracts
resolveMedium(request) -> Resolution
request: lane, argument?, userConfig?, projectRoot?, teamRef?
Resolution: preferred?, medium, decidedBy, notices[]
Rules: the argument decides alone. Each scope's own value is read separately (cascade file reader
and schema check, not resolve()'s merged output; team file optionally from teamRef). terminal/file
from any scope keeps the view local. Else the first publishing value from a trusted scope wins:
personal override (untracked and gitignored only), then userConfig. With no scope deciding, the
plugin default applies (trusted: the installed plugin); "any scope" never includes the plugin default. A team file never publishes; an invalid value is ignored without dropping another
scope's value; auto equals unset. Retired files (~/.claude/rendered-views.md,
.claude/rendered-views*.md) produce notices, never values.
CLI: view-settings resolve --lane <id> --option <user_config.medium> [--argument <m>] [--team-ref <ref>]
MediumEntry { id, publishes, reachable(context) -> {ok, reason}, deliver(view, context) -> {location}, reportName }
SurfaceEntry { id (terminal | page | shared-session; a shared-session variant is a new entry),
available(context) -> {ok, reason}, start(session) -> handle, reportName }
ViewKindEntry { id, parse(record) -> data, template, tier }
Lane registration: { laneId, kinds[], hostedCapable }
Fallback chain (medium registry): artifact, file, terminal; hosted read as artifact unless hostedCapable.
Skills call resolveMedium, render(laneId, kind, record), resolveSurface; they never name a medium,
surface or kind value in their own prose.
Report line: view: <medium> (<decidedBy>), plus one line per notice.
PageInput { kind: lock | unlock | comment, recordId, choiceId?, optionId?, text?, at }
- untrusted data; the session reads only these fields; a lock is written to the record, never approval
- delivery: file via the session bridge; terminal via the conversation; Artifact via a
"Copy choices as prompt" control (existing runtime copy binding) the owner pastes; the page says
live lock needs the local page
- unhandled input is collected at the start of the owner's next message
Redraw binding: a choice names the example blocks it selects; client-only, no network, no storage.
Done when
- AC4 / AC7 / AC15: a git grep for an enumerated medium list in the work-items plugin's skills and evals finds none; the work-items evals validate with no FAIL; no model evals are run.
Out of scope
- Other plugins
- Vocabulary fixes (vocabulary slice)
Activity
github-actions commentedon Nov 3, 2026
github-actions commentedon Nov 3, 2026
melodic-automation-lanes commentedon Nov 3, 2026
The work-resolve-issue lane stopped partway through this issue and needs a person.
Reason:
designWhy, in the run's own words:
What the run says it did not do:
Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41580973865
To retry, remove
needs-humanand addagent-readyagain.github-actions commentedon Nov 3, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: #12667
I understood this as a bounded refactor. work-items:triage should resolve its view medium through the shared resolver CLI and print the
view:report line. The work-items skills and evals should name no enumerated medium values, and the work-items evals should validate with no FAIL.An earlier lane run stopped because the resolver this depends on is not on the default branch yet. #12667 is still open, so this issue is blocked by it. The scope and done-when are exact, so nothing is missing from the issue itself. I found no duplicate among the open issues.
Automated triage, applied by the lanes App.
6 remaining items
github-actions commentedon Nov 3, 2026
melodic-automation-lanes commentedon Nov 3, 2026
The work-resolve-issue run that
agent-readystarted waited in its slot past a change to its lane workflow files on main, so it stopped before any model turn. The run's report-outcome removed and addedagent-readyback to start a fresh run on main's workflow files. If this run ends the same way, it re-fires the issue again, waiting longer each time.github-actions commentedon Nov 3, 2026
github-actions commentedon Nov 3, 2026
melodic-automation-lanes commentedon Nov 4, 2026
The lanes App's pull request #12970 for this issue was closed without merging. work-unblock removed
status: readyandagent-ready, so the hourly triage sweep sends it back to intake triage, which decides what work is left and admits it again.kyle-sexton commentedon Nov 4, 2026
Done on main after #13019 (triage board) and #13025 (morning-brief) merged. AC4 / AC7 / AC15: a git grep over plugins/work-items/skills for an enumerated medium list finds none; the remaining mentions name one medium as eval fixture setup or a report line (triage/evals/evals.json:523-537, morning-brief/evals/evals.json:120-121). check-evals-quality on both evals.json files: PASS, no FAIL. No model evals were run.