fix(provider): resolve repo skills per workspace by donjor-agent[bot] · Pull Request #188 · RSI-Software/t3code-hyprws

donjor-agent · 2026-08-28T07:18:31Z

Repo-local skills and slash commands now resolve against the active project or worktree for Codex and Claude.

Scenario: Codex

before:

now:

Scenario: Claude

before:

now:

Scenario: Project switching

before: provider discovery reused startup-directory results.

now: each project or worktree supplies its own working directory and cache key; assignee verification is pending.

Mechanism

Add one authenticated workspace-skills RPC shared by web, contracts, and server.
Resolve project and worktree paths on the server before provider discovery.
Query Codex app-server skills per working directory.
Cache Claude discovery per working directory.

Refs #182. Remaining condition: the PR assignee verifies Codex, Claude, and cross-project isolation before issue closure.

Built by Codex on GPT-5.6-sol (high).

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes

Refs #182 Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes

donjor · 2026-08-28T07:29:03Z

Known limitation

New skills aren't loaded; unsure what trigger is
works in cli

non-blocking

donjor-agent · 2026-08-28T07:54:00Z

🤖 codex/openai gpt-5.6-sol (high)

Diagnosis: provider discovery is live; the composer query is stale.

workspaceSkills has a 30-second stale window and revalidates only on mount, with no polling or invalidation signal.
A New thread draft in the same project keeps the same query key, so creating t3code-test-skill while that view stays mounted sends no second discovery request.
Standalone Claude succeeds because a fresh CLI process rescans the working directory.
On T3's next request, Claude scans disk directly and Codex starts a fresh app server and calls skills/list, so provider caching is not the blocker.
Current refresh: reload the client, or navigate away and back after the 30-second stale window.
Follow-up: invalidate from workspace file changes; Codex exposes skills/changed, while Claude needs equivalent filesystem invalidation.

Non-blocking for this PR.

Refs #182 Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <donjordev@gmail.com>

… commit ## What Changed Record `fix(provider): resolve repo skills per workspace (#188)` as a partial retirement in `docs/internals/fork-delta.md`. The superseded scope goes in Retired. The remainder stays in Kept. ## Why The unblock walk onto `v0.0.39-nightly.20260902.1261` reduced that commit from 546 insertions across 17 files to 35 insertions across 2 server files. ```diff - providers.workspaceSkills RPC, contract schemas, client atom family, chat-view preference, Codex pair + cwd-keyed Claude capabilities probe cache at capacity 16 + slashCommands merged alongside skills in upstream's snapshotForCwd ``` Upstream `bc918e7` (`pingdotgg#9210`) supplies per-workspace provider snapshots: `snapshotForCwd` on every driver, `refreshWorkspaceSnapshot` in the registry, `workspaceSnapshots` on `ServerProvider`, and the client resolvers. That is what supersedes the dropped scope. Upstream's `snapshotForCwd` merges `skills` alone. Its capabilities probe cache stays capacity 1, keyed on binary plus resolved HOME. The remainder covers exactly that gap. A subject in both Retired and Kept is how the ledger spells a partial, so the commit stays in the stack. **Checks** - `vp run fork:delta --check`: ok, 220 fork commits tagged. - `vp run fork:upstream-refs docs/internals/fork-delta.md`: unchanged at 8 pre-existing live references. The new Retired row code-spans its subject and adds none. The 8 predate this branch. `#492` stays open. Its first `Done when` is a user-visible claim, that a project's `.claude/commands` appear in the Claude menu for a worktree thread. No client pass has been run, so this cannot close it. Refs #492 Refs #481 Fork-Domain: fork-meta Fork-Tier: qol Fork-Upstreamable: no Co-authored-by: donjor <38745786+donjor@users.noreply.github.com>